Using ClassInterfaceType.AutoDual is really a bad idea, even with VB6?

Question

I've written a simple .NET project (Class Library) that is COM visible. It works with VB6!

The code looks like following:

[ComVisible(true)]
[ClassInterface(ClassInterfaceType::AutoDual)]
public ref class MyObject
{
    // Some methods and values
}

The assembly is properly signed (not required if it is not in GAC) and registered (regasm MyProject.dll /tlb /codebase).

Then, the TLB file is referenced in my VB6 project and all is OK! I could access at my classes and the public methods inside them.

On the Internet, many people say that using ClassInterfaceType::AutoDual is not a good idea, because of potential problems with versioning that could break applications that used the assembly.

But, in my case, is it really a problem? This assembly is only used in VB6 projects (in early binding).

In every new release, I do back theses steps (signed, registered and so on). Can it be any versioning problem with this solution?

Anyway, can I have write some [GUID("...")] attributes?

The GUIDs are generated automatically by Visual Studio, so classes aren't the same GUID at each compilation. Is it right?

Answer 1

Early binding in VB6 cannot work if you don't use AutoDual. Also, auto-completion no longer works in the VB6 editor so the risk for typing mistakes that cause a runtime error are higher. VB6 programmers tend to be used to this so may well insist on it.

Sure, it is risky. If you update the COM server and make the mistake of specifying the [Guid] and not updating it then there's a substantial risk that the VB6 program will crash at runtime with a completely undiagnosable error. Or worse, not crash at all but call the completely wrong method.

If you let .NET auto-generate the [Guid], highly recommended, then you don't get a hard crash but a "ActiveX component can't create object" error at runtime. Which is a bit more helpful and certainly less dangerous but gives you or the user very little guidance on where to look for the problem.

If you use ComInterfaceType.InterfaceIsIDispatch then the VB6 programmer is forced to use late binding and use GetObject() to create the object. The [Guid] doesn't matter much anymore and there are higher odds that existing VB6 code can still use the COM server if the changes are not too radical. It still bombs if, say, a method acquired an extra argument. There will be a better runtime error for it. Not otherwise a cure for a change in the logic of the method that the VB6 programmer didn't count on of course. A disadvantage is that a method call will be substantially slower.