Probelm with COM-interop in a webservice

[Marco]

Hello!

DESCRIPTION
===========

I've registered a COM DLL containing several coclasses:

coclass PlainVanillaObj
{
[default] interface IPlainVanillaObj;
};
[
uuid(AA2715F9-6EF6-40D3-9CFF-04069358221D),
helpstring("PathTableObj Class")
]
coclass PathTableObj
{
[default] interface IPathTableObj;
};
[
uuid(ECC7E8C4-3373-40B3-BC2A-50868F054721),
helpstring("CPPIStrategyObj Class")
]
coclass CExchangeableBondObj
{
[default] interface ICExchangeableBondObj;
};

Both ICExchangeableBondObj and IPlainVanillaObj define the following
method:

[id(3), helpstring("method SetAsset")] HRESULT
SetAsset([in]IPathTableObj *pPathTbll);

...which simply saves the pPathTbll pointer in a local member.

I've added a reference to the COM-DLL inside a C# project (in VS.NET)
from which I can now create instances of these classes and call their
methods:

PathTableObjClass eqtyPath = new PathTableObjClass();
PlainVanillaObjClass pv = new PlainVanillaObjClass();
CExchangeableBondObjClass ex = new CExchangeableBondObjClass();
eqtyPath.SetNormal( 1,0);
pv.SetAsset( eqtyPath);
ex.SetAsset( eqtyPath);

Everything WORKS FINE in a C# console appplication: "eqtyPath" is
initialised by "SetNormal" and its pointer is saved in local members for
"ex" and "pv" by "SetAsset" (untouched by my code).

PROBLEM
=======

When I run the same code inside a C# webservice, everything works fine
for object "pv" ("SetAccess" stores the good pointer without mangling
it) but object "ex" receives a *DIFFERENT* pointer than the "eqtyPath"
one (and everything crashes of course!) .

There's something in calss "CExchangeableBondObjClass" which prevents it
from receiving pointers to "IPathTableObj" objects when used inside a
webservice!

Note that threading model is "Apartment" for all classes and they were
all created by adding "COM-ATL components" to an ATL project (so AFAIK
there's no difference between them).

How do you explain that?

Thank you!

Cheers

-- Marco --

 

[Marco]

Hello!

I've discovered that the DLL was badly registered and the Threading
model for the faulty class (CExchangeableBondObj) was still set to
"Both" instead of "Apartment" which caused its objects to be treated as
"thread safe" inside the webservice (the ASPNET process runs in MTA
environment - i.e. multithreaded) although they were not meant to be.

The problem wasn't exposed by the C# console application since its
default threading model is STA (single threaded environment).

You can find more on this issue inside "The .NET and COM
Interoperability Handbook" By Alan Gordon (O'Reilly).

Cheers!

-- Marco --