M
mariescottandeva
Hi,
I need to call an old C DLL from my Web Service. This in itself is
fine and I am able to do this no problem. My issue is that I need to
call the DLL thousands of times, and it has memory leak and memory
corruption problems, so after a while it dies with a memory corruption
error. I donot have the option of fixing the memory leak, so I need
to come up with a solution.
my understanding is is the once an external dll is imported into the
ASP worker process using the dllimport command that it cannot be fully
unloaded and released (I've tried lots of examples on the net, even
calling Win32 API calls to unload the DLL).
My proposed solution is the wrap the calls to the dodgy C dll in an
out of process application written in VB6 (ActiveX EXE). As the code
will be running outside of the ASP worker process, I can then easily
release the COM object and will not have the dodgy memory corruption
in my ASP.NET app.
I know this solution will probably slow things down a hell of a lot,
but it will work ? The only option I have at the moment is to restart
IIS when the old dll goes bang.
Has anyone used this technique before, and is my proposed solutino
viable ?
Cheers
I need to call an old C DLL from my Web Service. This in itself is
fine and I am able to do this no problem. My issue is that I need to
call the DLL thousands of times, and it has memory leak and memory
corruption problems, so after a while it dies with a memory corruption
error. I donot have the option of fixing the memory leak, so I need
to come up with a solution.
my understanding is is the once an external dll is imported into the
ASP worker process using the dllimport command that it cannot be fully
unloaded and released (I've tried lots of examples on the net, even
calling Win32 API calls to unload the DLL).
My proposed solution is the wrap the calls to the dodgy C dll in an
out of process application written in VB6 (ActiveX EXE). As the code
will be running outside of the ASP worker process, I can then easily
release the COM object and will not have the dodgy memory corruption
in my ASP.NET app.
I know this solution will probably slow things down a hell of a lot,
but it will work ? The only option I have at the moment is to restart
IIS when the old dll goes bang.
Has anyone used this technique before, and is my proposed solutino
viable ?
Cheers