dotnet component services: We have implemented a ServicedComponent which is accessed by other COM+
components written in VB6. It's OK for for us to register the
ServicedComponent and we successfully put it into the same COM+ Application
(activated as Server instead of Library) with its client components.

Everything goes well for the other COM+ components to access this
ServicedComponent. However, when the client component is done, the
ServicedComponent is still spinning in the Component Service Explorer.

While we understand that calling Dispose() should correct this problem if
the client is written in .NET, we can't replace the existing VB6 component.
Is there anything we can do to release these ServicedComponent instances?
Any help is much appreciated...

David

I figured out a workaround for the problem that I am having and would like
to share with you all who may have the same problem.

Our COM+ application is a "Server" application and have security enabled
with an domain account as its identity, say "Identity_Account". What we
figured out is that whenever COM+ application security is disabled, the
ServicedComponents get released by the genuine COM+ clients without any
problem.

Whenever COM+ application security is enabled, we get a bunch of NT events
raised by COM+ saying that the call to IDisposable of all ServicedComponents
was rejected and all these calls are made by "Identity_Account" - this
explains why the ServicedComponents are not released...

I am not sure why the application's own running account can be rejected by
COM+ for accessing its own components' IDisposable interface... Would be
grateful if someone can share any insight on this. (could this be indeed a
bug in COM+ or .NET ServicedComponent?)




[quoted text, click to view]