We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


Problem upgrading ISAPI Extension from VC++5.0 to VC++.NET

Medium Priority
Last Modified: 2013-11-25
Hi Experts:

I have this app. that is running for almost 2 years now. It consists of an application server that is accessed by the ISAPI dll - both writen in C++ - on the server side. On the client side it has an Active/X control (.ocx) embedded in regular HTML that creates an http session with the isapi dll thru the IIS and communicates with it. This ocx is written in MFC based C++.

All this is in use on an NT4.0 server with IIS 4.0. Now I am upgrading it to Windows 2000 , IIS 5.0 and VC++.NET.

So far, all VC++5.0 modules install and run OK in the new server. The problem arises with the .NET version of the ISAPI Dll, which is compiled in the same server. I placed traces that write to the event viewer from each method of the isapi extension and found out that only the constructor and the GetExtensionVersion method are getting invoked, while the Default method is not. The funny thing is that when the same code is compiled using VC++5.0 on a win95 pc, everything works fine.

The following data refers to the environment I have on my lab to get this thing to work:

Windows 2000 5.00.2195 - Service Pack 2
IIS 5.0
Visual C++.NET
  MS Development Environment 2002 Version 7.0.9500
  MS .NET Framework 1.0           Version 1.0.3705

Windows 98 Second Edition
IE 5.00


Watch Question

Check the dependeces of your new DLL. Probably the .Net code linked to your C++ code depends on the some new DLL(s) loaded dynamically at run-time and you didn't put it on IIS computer.


Hi Yuri,

There are 2 facts I´d like to mention now.
First is that I forgot to mention that just in order to prevent this kind of dependences problem, the DLL is linked to MFC as a static library. Second, the DLL is actually running (it is posting events to the event viewer from 2 methods) but the "Default" method does not receive control at any time.
This means to me that when the first request for the dll comes from the client, the IIS loads and instantiates the dll (which in turn posts the trace events from the methods mentioned) and then the IIS fails to locate the entry point for the "Default" method, and nothing more happens with the dll, until the IIS is restarted. At this time, the IIS terminates the dll, what I can see in the event viewer by an event posted by the dll destructor method.
When I found out that just one method was not being invoked, I tried to fix it in the .def file wher the wizard didn´t include default as an export. First the linker failed because it found redundancies with the name "default" and asked for a decorated name. Then I got this decorated name (without fully understandig the rules of decoration) using the dumpbin utility and put it in the .def, forcing the linker to success.
But the results were the same, whether omitted or included decorated in the .def, the default method is not getting invoked.

Should I try using MFC as a DLL? What is a decorated name? Why do I get duplicates when I put Default(undecorated) in the .def?

Thanks for your comments, and looking forward for further comments.

IIS invokes GetExtensionVersion when it loads DLL first time then only HttpExtensionProc. Even you defined in *.def file "Default" method it doesn't change anything. Check if HttpExtensionProc in *.def file. And if yes add some traces up to Default method call walking though the code.


HttpExtensionProc is in *.def file already. Default method is starting with a trace, this is how I notice it´s not being invoked.
Unlock this solution with a free trial preview.
(No credit card required)
Get Preview


Hi Yuri,

There was no HttpExtensionProc override in the original code, the wizard didn´t put it either and it was needed never before. So I added it by hand just to place a trace as you suggested and .... voila !! Now everything works fine. It looks like, for some reason, the new compiler requires this override to be coded by hand in the dll extension.
Thank you very much for your help. The 500 points and the grade are yours, but it is much more what you deserve.

Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a free trial preview!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.