IIS 5 & IIS 6
Problems running DLL ISAPI Extension
Last post Jun 21, 2006 01:46 PM by rstrahl
Jun 16, 2006 05:19 AM|rstrahl|LINK
I ran through installation of an older Application Server based on an ISAPI implementation with IIS 7. I was able to get the application configured to run without any major issues using application/script maps, but I can't for the life of me get the DLL to
I have several script maps to this DLL which lives in a Virtual directory. Those script maps work fine. However accessing the DLL directly fails with a File Open dialog from IIS.
What am I missing here so that direct DLL links can run?
I can make this work by using all script map links, but it there are lots of relative links around that point at the DLL directly so I still need that to work...
Any help appreciated,
+++ Rick ---
Jun 16, 2006 11:28 AM|mvolo|LINK
Can you post the detailed http error message you are getting, and if possible the FREB trace for the request?
You can turn on FREB tracing by following this walkthrough:
Jun 16, 2006 01:35 PM|iiscool|LINK
Rick - I think the most common problem when attempting to use an ISAPI dll for other direct references is the DllMain() entry point. That entry point could be needed for direct access but not required if the dll is being used
as an ISAPI extension\filter. If your were able to access those Dlls directly in the past then this might not be the issue but just somethig to look at...
MVolo - Not sure if he would have those logs since he says that the scriptmaps run fine and the failure only occurs if he calls those dlls directly...
Jun 16, 2006 10:43 PM|rstrahl|LINK
Hooked up the Failed Request Logging but nothing is showing up in the log folder. I don't think it's getting there. IIS is serving the file as a binary image - it's not treating it as an application extension.
IOW, i don't think it's not being treated as a failed request, just not being served as the proper type of request.
Here's what IIS sends back (minus the binary content <g>):
HTTP/1.1 200 OK
Last-Modified: Sat, 17 Jun 2006 02:24:13 GMT
Date: Sat, 17 Jun 2006 02:33:30 GMT
which is the content of the file...
As I mentioned script maps work fine so the ISAPI Extension DLL itself is fully functional and working, but IIS is not treating it as dynamic content.
I do have Scripts and Executables enabled on the virtual where the DLL lives and the diretory on disk allows the anonymous user read and execute rights. Just for kicks I added EveryOne just to make sure, but same result.
In IIS 6 without those file system permissions I'd get the behavior like above, but with the permissions set it should work...
Jun 16, 2006 10:44 PM|rstrahl|LINK
Jun 18, 2006 02:17 PM|mvolo|LINK
Can you confirm that you have a script-map that looks like the following:
path=*.dll verb=* modules="IsapiModule" scriptProcessor="" requireAccess="Execute"
This is what causes the direct access to the *.DLL files to be loaded and executed as an ISAPI extension, as opposed to by the static file handler.
It sounds like you already have the ISAPI module installed otherwise you would be failing to load the scriptmaps with scriptProcessor set to the DLL.
Jun 19, 2006 08:59 PM|anilr|LINK
Jun 20, 2006 04:18 AM|rstrahl|LINK
Yes indeed, this was the problem. I'm not sure how this happened but when I went to the directory I noticed that all handlers were removed EXCEPT for the scriptmaps.Adding the ISAPI-DLL module into the list made it work.
Eh, operator error <g>...
BTW I think the naming in the handlers dialog is a little misleading. Add Module Mapping for the adding a built-in HANDLER seems like the wrong naming convention. I suspect the module list that pops also isn't a 1-1 match to what you can actually use. I
don't suppose you can use the AnonymousAuthenticationModule as a Handler?
Thanks for your help,
Jun 21, 2006 12:58 PM|mvolo|LINK
Glad to help - btw, with clearing the handler list, you are also losing a number of other handlers you may want so be prepared :).
Re: the UI dialog, I feel your pain :) Combining the module and handler notions here is misleading - the fact that you can map a request to some native modules is just an artifact of how native modules provide request handling, and I wish we hadnt exposed
it at the top level.
Would you be ok with losing the "suggestion" list of modules if that naming went away, and having to type in the native module that provides the desired handling? This would be equivalent to IIS6 where you had to type in the ISAPI name if you were creating
a new handler mapping. But, as you note you have to know the name of the module you want anyway, since AnonymousAuthenticationModule does not serve any content :)
Jun 21, 2006 01:46 PM|rstrahl|LINK
Well, it's not me that I'm worried about <g>. I can probably figure it out, but I'm thinking more about our typical customer who's intimidated by IIS Admin anyway <s>... If I'm documenting the settings, it's hard to explain to say module when I mean handler
- it gets completed.
I have to say that the the module list is a nice feature. I've had lots of occasions in the past were I needed to set up custom script maps to the ASP.NET ISAPI DLL and that process is tedious (open the ASPX extension, copy the DLL reference, add the new
scriptmap and paste it) - so I can appreciate the module drop down.
What would be nice if the 'module list' was filtered to show only those modules that include handlers. There's gotta be some sort of marker there (IHttpHandler for managed handlers - something similar in the unmangaged modules) that could be checked by the
interface to show only eligable modules. Then you could name them handlers.
If that can't be done I think I would like to see the dialog reference the 'modules' as handlers.