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

Question

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

The code is as follows:

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

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

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

On the Internet, many say that using ClassInterfaceType::AutoDual not a good idea, due to potential version problems that could disrupt applications that used the assembly.

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

In each new issue, I return theses (signed, registered, etc.). Could this be a problem with the version with this solution?

In any case, can I write some attributes [GUID("...")] ?

Visual Studio automatically generates GUIDs, so classes are not the same GUIDs for each compilation. Right?

Answer 1

Early binding in VB6 may not work if you are not using AutoDual. In addition, autocomplete no longer works in the VB6 editor, so the risk of typing errors that cause a runtime error is higher. VB6 programmers are usually used for this, so they may well insist on it.

Of course, this is risky. If you update the COM server and make an error while specifying [Guid] and do not update it, there is a significant risk that the VB6 program will crash at runtime with a completely non-error error. Or, even worse, not a failure at all, but a call to a completely wrong method.

If you allow .NET to automatically generate [Guid], it is highly recommended that you do not get a hard crash, but the error "ActiveX component cannot create object" at runtime. This is a little more useful and, of course, less dangerous, but gives you or the user very few recommendations as to where to look for the problem.

If you are using ComInterfaceType.InterfaceIsIDispatch, then the VB6 programmer is forced to use late binding and use GetObject () to create the object. [Guid] doesn't really matter, and there is a higher chance that existing VB6 code can still use the COM server if the changes aren't too drastic. It is still bombing if, say, the method received an additional argument. There will be a higher runtime error for it. Otherwise, there was no cure for changing the logic of the method, which, of course, was not expected by the VB6 programmer. The disadvantage is that the method call will be much slower.