About protected memory in COM(in-process)

[Tony Johansson]

Hello!

For several years ago an in-process COM dll was deleloped using ATL/C++/MFC
This in-process COM DLL was initially used from VB6 and it has worked ever
since then and still works today
without any kind of problem.
It has never ever been any kind of problems with this COM dll.

For about 7 month ago a C# asp.net webb application was deloped where this
in-process COM DLL was used.
When this C# asp.net webb was finished and put into test where the COM dll
was called error began to appear.
Not every time but far too often. It wasn't reliable.
The errors that appear was the protected memory.

Now to my question:
How is possible that the exact same COM dll work just perfectly when being
run under windows VB6 and not from
C# asp.net webb application. One major differens here is that they are being
run under different environment.
In the second case when a C# asp.net webb application is running it's the
Internet Information Service(IIS) that is running the code.

So for me it sounds strange that there could be programming errors in the
COM dll when the COM dll works
perfect when being called from VB6.

Could it be as simple as it's not fully supported or not recommended to use
in-process COM dll from C# asp.net webb application.

I mean that if the COM dll had some error it would appear when being used
from an application developed in VB6

Nothing makes sense in this difficult question.

Can somebode give a comment about this.

//Tony

 

[bruce barker]

yes, there are problems using com dlls from asp.net. first the com dll should
be mta, not sta (say a vb6.0 com object).

if its a sta com dll, then you need to do some work. as asp.net is thread
agile (switches threads during the request processing) and sta com objects
will fail in this enviroment.

to get around this, with web pages you set aspcomp="true" on every web page
that uses an sta com object (there will be a performance hit for doing this).


if you have a webservice, there is no aspcompat flag. you will need create
an sta thread to call the com object on in the web service. for a solution
see:

http://msdn.microsoft.com/en-us/magazine/cc163544.aspx

another issue is releases. in .net the release is only called when gc
releases the com object wrapper. as .net has no knowledge of the memory
allocated by the com object, this can take a long time as the wrapper is
small. this can lead to serious memory "leaks".

to get around this you should call Marshal.ReleaseComObject() whenever your
code is done with it. in order to always release, you should follow the one
dot rule. never use more than one dot when accessing a com object. if you use
2 dots, say a.b.c, the you can not release the temporary object b as you do
not have a handle to it.

-- bruce (sqlwork.com)