BenRush:
..yes, you'll need to install the atlas bits on the server too. This will register the .asbx extension with IIS and install the client scripts (debug and release).
Time and time again I have seen replies that it is not necessary to actually install the .exe on the remote server, only that the dll needed to be in "bin" and the "ScriptLibrary" in the application root...
So what are people using shared hosting to do?
I had it go from not working to "working" immediately after running the installer...I could be wrong. If you don't run the .exe, then you'll have to manually register the .asbx with IIS if'n the situation arises that it needs to be. I haven't encountered a situation yet where that's the case, though.
hello.
yep, not running the exe won't add the necessary configurations to IIS (though these can be done by hand without any problems). btw, if you can't register the asbx extension, you can still use bridging by enabling the bridgemodule (hope i got the name right)...
I'm not sure what the bridgemodule actually does, the only pertinent spot of code in the whole module seems to re-route requests from bridge.axd to bridge.asbx. I don't think the bridgemodule does anything but clean HTTP requests. I could be grossly mistaken, however.
I think it's the bridge build provider that you're interested in if you want to still support bridging, as this is what compiles the .asbx files to types that can be found by the runtime type loader, etc. during request handling time. It appears as though .asbx extensions simply get ripped off the end of the request and the data type gets pulled out of the assemblies for the running web application by name.
So, http://www.blah.com/blah/bling/blong/mytype.asbx
ends up getting resolved by something like,
string s = path.GetFileNameWithoutExtension(virtualpath);
Type.GetType(s);
No comments:
Post a Comment