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

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:

SERVER
------
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

CLIENT
------
Windows 98 Second Edition
IE 5.00


Regards

Julio
juliogonzalezAsked:
Who is Participating?
 
YuriPutivskyCommented:
You can trace it. Put trace staements starting from HttpExtensionProc. Or even better you can do it under debug and see what's going on exactly.
0
 
YuriPutivskyCommented:
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.
0
 
juliogonzalezAuthor Commented:
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.

Julio
0
Cloud Class® Course: Ruby Fundamentals

This course will introduce you to Ruby, as well as teach you about classes, methods, variables, data structures, loops, enumerable methods, and finishing touches.

 
YuriPutivskyCommented:
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.
0
 
juliogonzalezAuthor Commented:
HttpExtensionProc is in *.def file already. Default method is starting with a trace, this is how I notice it´s not being invoked.
0
 
juliogonzalezAuthor Commented:
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.

Julio
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.