Korzystanie z ClassInterfaceType.AutoDual jest naprawdę zły pomysł, nawet z VB6?

Question

Napisałem prosty projekt .NET (Class Library), który jest widoczny COM. Działa z VB6!

Kod wygląda następujące:

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

Zespół jest prawidłowo podpisany (nie jest wymagany, jeśli nie jest w GAC) i zarejestrowany (regasm MyProject.dll /tlb /codebase).

Następnie plik TLB jest przywoływany w moim projekcie VB6 i wszystko jest OK! Miałem dostęp do moich zajęć i dostępnych w nich metod publicznych.

W Internecie wiele osób twierdzi, że używanie ClassInterfaceType::AutoDual nie jest dobrym pomysłem, z powodu potencjalnych problemów z wersjonowaniem, które mogą przerwać aplikacje, które używały zespołu.

Ale, w moim przypadku, czy to naprawdę problem? Ten zestaw jest używany tylko w projektach VB6 (we wczesnym wiązaniu).

W każdym nowym wydaniu wykonuję te same czynności (podpisane, zarejestrowane itd.). Czy to rozwiązanie może być problemem z wersjami?

W każdym razie, czy mogę napisać jakieś atrybuty [GUID("...")]?

Identyfikatory GUID są generowane automatycznie przez program Visual Studio, więc klasy nie są tym samym identyfikatorem GUID w każdej kompilacji. Czy to jest poprawne?

Answer 1

Wcześniejsze wiązanie w VB6 nie działa, jeśli nie korzystasz z AutoDual. Ponadto automatyczne uzupełnianie nie działa już w edytorze VB6, więc ryzyko popełniania błędów, które powodują błąd środowiska wykonawczego, jest wyższe. Programiści VB6 zwykle są do tego przyzwyczajeni, więc mogą nalegać na to.

Oczywiście, jest to ryzykowne. Jeśli zaktualizujesz serwer COM i popełnisz błąd, określając [Guid] i nie aktualizując go, istnieje znaczne ryzyko, że program VB6 ulegnie awarii w czasie wykonywania z całkowicie niemożliwym do zignorowania błędem. Lub gorzej, nie rozbić się w ogóle, ale wywołaj całkowicie niewłaściwą metodę.

Jeśli pozwolisz .NET automatycznie wygenerować [Guid], wysoce zalecane, to nie dostaniesz twardej awarii, ale "Środowisko ActiveX nie może utworzyć obiektu" błąd w czasie wykonywania. Co jest trochę bardziej pomocne i na pewno mniej niebezpieczne, ale daje ci lub użytkownikowi bardzo niewiele wskazówek, gdzie szukać problemu.

Jeśli użyjesz funkcji ComInterfaceType.InterfaceIsIDispatch, programista VB6 będzie zmuszony użyć późnego wiązania i użyć funkcji GetObject() w celu utworzenia obiektu. [Guid] nie ma już większego znaczenia i są wyższe szanse, że istniejący kod VB6 nadal może korzystać z serwera COM, jeśli zmiany nie są zbyt radykalne. Nadal bombarduje, jeśli, powiedzmy, metoda uzyskała dodatkowy argument. Będzie dla niego lepszy błąd czasu wykonania. W przeciwnym razie nie byłoby lekarstwem na zmianę logiki metody, której programista VB6 oczywiście nie liczył. Wadą jest to, że wywołanie metody będzie znacznie wolniejsze.