Calling old C DLL for ASP.NET Web Service

[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

[Juan T. Llibre]

Have you tried creating a wrapper for the DLL with TLBIMP.exe?

TLBIMP ComponentName.dll /out:NewName.dll

That will create a .Net assembly from your C DLL.

There are exceptions (some DLL functions can't be imported into a wrapper assembly),
but for the most part TLBIMP can do the job. Try it and see.

Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
<ma**************@gmail.comwrote in message news:ef**********************************@34g2000h sf.googlegroups.com...

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

[mariescottandeva]

Thanks for the response I'll give it a go and let you know how I got
on.

Cheers

[mariescottandeva]

It won't work for me. TLBIMP converts the type definitions found
within a COM type library into equivalent definitions in a common
language runtime assembly.

My C DLL is not a COM dll. :(

[Mark Rae [MVP]]

<ma**************@gmail.comwrote in message
news:ef**********************************@34g2000h sf.googlegroups.com...

Has anyone used this technique before,

Yes, but had to abandon it as performance degradation was unacceptable...

and is my proposed solution viable ?

Technically, yes. Practically, depends on how slow it actually is in the
real world...

I'm presuming that you no longer have the source code for the DLL...?
--
Mark Rae
ASP.NET MVP
http://www.markrae.net

[Juan T. Llibre]

re:
!It won't work for me.
!My C DLL is not a COM dll

Drats!
It was worth a shot anyway. Sorry for not having been able to help more.

Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
<ma**************@gmail.comwrote in message news:16**********************************@59g2000h sb.googlegroups.com...

It won't work for me. TLBIMP converts the type definitions found
within a COM type library into equivalent definitions in a common
language runtime assembly.

My C DLL is not a COM dll. :(

[mariescottandeva]

Hi Mark,

No I don't have acesss to the old C code, so trying to fix the leak
is'nt viable.

Good to hear that technically what I am trying to achieve is possible.

One thing that is important though is performance, so the fact that
you had to abandon the venture because of performance problems might
mean that what I am trying to do might not be a sutiable solution. I
will give it a go though.

One other thing to mention, I stated originally that I need to call
the C DLL thousands of times. The C DLL is not thread safe (It's not
a great DLL :) ), however, as it will now be runnning in its own
process. I am considering using the thread pool to call it lots of
times on seperate threads. Each thread will affectively will create a
seperate process to call my C DLL. I will then get each thread to
release the out of process server when finished.

I am hoping that the speed benefits I can use by utilising multiple
threads will offset any perfomance degradation caused by created the
out of process server.

The web server I am using for the app is brand new and a decent spec
so it should be able to handle this without to much stress.

[Mark Rae [MVP]]

<ma**************@gmail.comwrote in message
news:9d**********************************@m73g2000 hsh.googlegroups.com...

No I don't have acesss to the old C code, so trying to fix the leak
is'nt viable.

That's a shame. How large / complex is the C DLL? Do you still have the
specs / documentation for it...?

Good to hear that technically what I am trying to achieve is possible.

One thing that is important though is performance, so the fact that
you had to abandon the venture because of performance problems might
mean that what I am trying to do might not be a sutiable solution. I
will give it a go though.

I will be very surprised if you can get it to perform at an acceptable
speed...

One other thing to mention, I stated originally that I need to call
the C DLL thousands of times. The C DLL is not thread safe (It's not
a great DLL :) ), however, as it will now be runnning in its own
process. I am considering using the thread pool to call it lots of
times on seperate threads. Each thread will affectively will create a
seperate process to call my C DLL. I will then get each thread to
release the out of process server when finished.

I am hoping that the speed benefits I can use by utilising multiple
threads will offset any perfomance degradation caused by created the
out of process server.

The web server I am using for the app is brand new and a decent spec
so it should be able to handle this without to much stress.

--
Mark Rae
ASP.NET MVP
http://www.markrae.net