I have a C#, COM-exposed .NET assembly, which I use heavily as a library for VB6 clients (Office VBA). I am extremely happy with it.
That same COM-exposed library is useful for me in some newer, .NET clients I have written as well. From Googling, the consensus is that the only way to do this is to reference the .NET libraries themselves (link 1, link 2), which I have done.
When these .NET apps are deployed, VS naturally wants to bring my COM .NET assemblies with them. But I now have several, independent copies of my COM assembly floating around with my .NET apps-- in addition to it being registered as a COM object on the machines in question.
This means that every time I make a bug fix or add functionality to my COM, I need to update these "floating" copies as well; which makes maintenance annoying at best. I want to expose my needed functionality once, for all apps that use it (isn't that the purpose of COM?!)
I tried activating the COM using late binding, hoping I could get around the problem-- but I got different behavior on two different machines, so I decided to ditch that idea.
Is there an elegant way to handle this? I thought perhaps it would make sense to register the COM assembly in the GAC upon installation, but it just seems like the wrong thing to do since it's already registered as COM (plus, it seems like registering in the GAC is not considered good practice).
I believe the easiest way to manage this scenario is to distribute the COM assemblies as a separate deployment that installs the assemblies to the GAC. When adding the assembly reference to the .NET projects, make sure the Copy Local property on the reference is set to False. This tells the .NET build to not include a copy of the assembly in the deployment, which ensures that both the deployed .NET app and the VB6 apps are both referencing the same version (the one installed in the GAC and registered with COM services)