L'utilizzo di ClassInterfaceType.AutoDual è davvero una cattiva idea, anche con VB6?

Question

Ho scritto un semplice progetto .NET (Libreria di classi) che è COM visibile. Funziona con VB6!

Il codice si presenta come segue:

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

L'assemblea è correttamente firmato (non richiesto se non è in GAC) e registrato (regasm MyProject.dll /tlb /codebase).

Quindi, il file TLB è referenziato nel mio progetto VB6 e tutto è OK! Potrei accedere alle mie lezioni e ai metodi pubblici al loro interno.

Su Internet, molte persone dicono che l'utilizzo di ClassInterfaceType::AutoDual non è una buona idea, a causa di potenziali problemi con il controllo delle versioni che potrebbe interrompere le applicazioni che hanno utilizzato l'assembly.

Ma, nel mio caso, è davvero un problema? Questo assembly viene utilizzato solo nei progetti VB6 (in associazione anticipata).

In ogni nuova versione, eseguo il backup di questi passaggi (firmato, registrato e così via). Può essere un problema di versione con questa soluzione?

In ogni caso, posso scrivere alcuni attributi [GUID("...")]?

I GUID vengono generati automaticamente da Visual Studio, pertanto le classi non sono lo stesso GUID in ciascuna compilazione. È giusto?

Answer 1

L'associazione anticipata in VB6 non può funzionare se non si utilizza AutoDual. Inoltre, il completamento automatico non funziona più nell'editor VB6, quindi il rischio di errori di battitura che causano un errore di runtime sono maggiori. I programmatori VB6 tendono ad essere abituati a questo, quindi potrebbe insistere su di esso.

Certo, è rischioso. Se si aggiorna il server COM e si commette l'errore di specificare [Guid] e non di aggiornarlo, c'è un rischio sostanziale che il programma VB6 si blocchi in fase di runtime con un errore completamente non diagnosticabile. O peggio, non si blocca affatto ma chiama il metodo completamente sbagliato.

Se si consente a .NET di generare automaticamente il [Guid], altamente consigliato, non si ottiene un arresto anomalo ma un errore "Il componente ActiveX non può creare oggetto" in fase di esecuzione. Il che è un po 'più utile e sicuramente meno pericoloso, ma offre all'utente o all'utente pochissime indicazioni su dove cercare il problema.

Se si utilizza ComInterfaceType.InterfaceIsIDispatch, il programmatore VB6 è costretto a utilizzare l'associazione tardiva e utilizza GetObject() per creare l'oggetto. Il [Guid] non ha più importanza e ci sono probabilità più alte che il codice VB6 esistente possa ancora utilizzare il server COM se le modifiche non sono troppo radicali. Bombarda ancora se, per esempio, un metodo acquisisce un argomento in più. Ci sarà un errore di runtime migliore per questo. Non altrimenti una cura per un cambiamento nella logica del metodo che il programmatore VB6 non contava naturalmente. Uno svantaggio è che una chiamata al metodo sarà sostanzialmente più lenta.