views:

107

answers:

1

Ok, imagine the simplest solution in Visual Studio 2008 with framework 3.5 (OS = Win XP) where I have added a class library. Then I've added a COM Class. This COM Class is so simple, it only exposes 1 function:

Public Function SayHello() As String Return " Hello." End Function

I've build this class library, which produced the .dll and the .tlb. I see the .tlb in VB6 app's references box (which is on the same comp), so I reference it. I call SayHello, run it, and... 'automation error'.

I found an article somewhere how to make a SetUp Project and then install the .dll. After I seperatly installed the .dll using this setup project the COM component works like it should in my VB6 app.

Ok, now for my question... WHY?! Can someone please explain to me what the setup project does that I apparantly didn't.

P.S.: Just to make it clear, it worked fine with VB2005 and Framework 2.0 ... But now I can't make this simplest example project to work.

+2  A: 

Unless you explicitly specify the UUIDs for the assembly's type library and all the COM-exposed classes and interfaces VS changes them automatically on each rebuild to prevent so-called "COM hell" (registry pollution with UUIDs).

Before compiling VS unregisters the previous version of assembly, then compiles the assembly and registers the new assembly. If the consumer (your VB application) has not been recompiled immediately it will now be unable to use the assembly because there's no data in the registry on the previous version of the assembly and corresponding type library.

To combat that you need to explicitly specify UUIDs for all the COM-exposed entities and then yoг'll have to maintain binary compatibility thoroughly.

sharptooth