dotnet uninstall breaks interprocess COM object events

[carl.clawson]

I have a package of COM objects written in C++ in version 6. It is
installed separately and shared by several applications. Then I have
a .NET application written in VS2005 that uses these objects. It is
installed by a .NET setup project. I excluded all the COM dll's so
that they don't get unregistered when the .NET app is uninstalled.
After uninstalling the .NET app I can still create objects but I
cannot assign an object to a "WithEvents" variable in VB6 if that
object is crossing a process boundary. In-process it works fine but
out-of-process it flings me an "automation error". All my COM events
are automation-compatible, discoverable with
IConnectionPointContainer, etc., and have not given me any trouble in
7 or 8 years of use until now.

Any clue what .NET is clobbering and how I can fix it? I've gone over
the setup project looking for anything funny, including the registry
keys, and whatever it is I'm missing it.

Thanks, Carl

 

[carl.clawson]

I have a package of COM objects written in C++ in version 6. It is

OK so I searched the registry before and after the uninstall and found
that .NET is unregistering an apparently random smattering of COM
interfaces. What I said above was not entirely correct...some objects
are missing more than just event interfaces.

VS2003 did not do this. If I exluded all the COM object DLLs from the
setup project, you could uninstall the .NET product and the rest of my
products still worked.

???? Help ????

-- Carl

 

[carl.clawson]

Nice little conversation I'm having with myself here.

The VS2003 statement was false. There was another change roughly
coincident with upgrading to 2005 -- we introduced an ATL COM object
in the .NET project, which uses #import to bring in some of the COM
interfaces it needs from the other installation. #import ends up
putting a random smattering of interfaces -- not all of them, just an
apparently random assortment -- into the type library of the new
component. This component then overrides their registrations and when
it's unregistered, poof!, they're broken. So now I go figure out WTH
#import is behaving this way and how to make it stop. I had this type
library stuff all figured out -- well, adequately figured out -- in V6
and now it's all different and just as poorly documented. Sigh.