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

i've written simple .net project (class library) com visible. works vb6!

the code looks following:

[comvisible(true)] [classinterface(classinterfacetype::autodual)] public ref class myobject {     // methods , values } 

the assembly signed (not required if not in gac) , registered (regasm myproject.dll /tlb /codebase).

then, tlb file referenced in vb6 project , ok! access @ classes , public methods inside them.

on internet, many people using classinterfacetype::autodual not idea, because of potential problems versioning break applications used assembly.

but, in case, problem? assembly used in vb6 projects (in binding).

in every new release, theses steps (signed, registered , on). can versioning problem solution?

anyway, can have write [guid("...")] attributes?

the guids generated automatically visual studio, classes aren't same guid @ each compilation. right?

early binding in vb6 cannot work if don't use autodual. also, auto-completion no longer works in vb6 editor risk typing mistakes cause runtime error higher. vb6 programmers tend used may insist on it.

sure, risky. if update com server , make mistake of specifying [guid] , not updating there's substantial risk vb6 program crash @ runtime undiagnosable error. or worse, not crash @ call wrong method.

if let .net auto-generate [guid], highly recommended, don't hard crash "activex component can't create object" error @ runtime. bit more helpful , less dangerous gives or user little guidance on problem.

if use cominterfacetype.interfaceisidispatch vb6 programmer forced use late binding , use getobject() create object. [guid] doesn't matter anymore , there higher odds existing vb6 code can still use com server if changes not radical. still bombs if, say, method acquired argument. there better runtime error it. not otherwise cure change in logic of method vb6 programmer didn't count on of course. disadvantage method call substantially slower.