Dlaczego dokładnie regasm ostrzega mnie przed podpisaniem pod silną nazwą?

Question

Jeśli chcę uczynić zestaw .NET użytecznym jako serwer COM, muszę dodać zestaw atrybutów, a następnie użyć regasm, aby zarejestrować go jako serwer COM.

Jeżeli zespół nie jest podpisany z silną nazwą regasm Uruchomiony z /codebase klucza pokazuje RA0000 ostrzeżenie mówiące, że zespół mogłyby kolidować z innymi zespołami na tym samym komputerze i muszę podpisać z silną nazwę, ale Rejestracja się udaje, a nawet działa dobrze.

Silne nazwy AFAIK mają na celu zapobieganie tak zwanemu piekłu w bibliotece DLL. Ale COM miał także zapobiegać piekłu w bibliotece DLL. Jeśli zmienię interfejs narażony na COM, muszę zmienić GUID lub przynajmniej zachować zgodność binarną. Dlatego podpisywanie się silną nazwą nie wydaje się być przydatne - nic nie przeszkadza mi w łamaniu interfejsów COM, a następnie podpisywaniu za pomocą tego samego klucza i posiadania pełnego piekła DLL.

Jaki jest pożytek z podpisu pod silną nazwą w przypadku złożonych zestawów .NET COM?

Answer 1

Jest to niezgrabne ostrzeżenie. Istnieją dwa aspekty COM DLL Hell. Naprawdę zły jest modyfikowanie publicznych interfejsów i nieprzypisywanie nowych identyfikatorów GUID. Aplikacja kliencka, która nie została zrekompilowana, ma tendencję do zawieszania się i nagrywania, gdy wywołuje całkowicie niewłaściwą metodę lub bomby z nieprzyjemnym wyjątkiem AccessViolationException, który nie daje żadnej wskazówki, co może być przyczyną.

Druga z nich robi wszystko poprawnie (przypisując nowe identyfikatory GUID), ale następnie zastępując istniejącą bibliotekę DLL nową wersją. Nadal będziesz zawieszać tę nieaktualną aplikację klienta, ale łagodniej z halerem E_NOINTERFACE, który generuje dość wyjątek, który pomaga zdiagnozować przyczynę. Użytkownik nie jest jednak szczęśliwszy.

Ten scenariusz ma gotowe rozwiązanie w .NET, GAC obsługuje równoległe wdrażanie złożeń o różnych numerach wersji, dzięki czemu zarówno stara, jak i nowa wersja mogą współistnieć, a aplikacja stale nie działa. być szczęśliwym ze starą wersją. Co wymaga silnej nazwy. Tak, to ostrzeżenie z pewnością można było zignorować, gdy używasz/codebase, ponieważ to wyjaśnia, że ​​nie zamierzasz używać GAC. Chociaż nie zaszkodzi poprawić nieco nos przy użyciu/codebase. Poza tym nigdy nie korzystasz z GAC na maszynie deweloperskiej podczas testowania, ale na pewno warto wziąć to pod uwagę podczas wdrażania.

Answer 2

Silne nazewnictwo służy głównie do umieszczenia bibliotek Dll w GAC. Więc możesz mieć kilka wersji biblioteki Dll o tej samej nazwie (!) Bezpiecznie na tym samym komputerze, co w zwykłych bibliotekach COM-DLL często powodowało problemy. Brak podpisania bibliotek dll usuwa możliwość GAC tego. Nie masz żadnych bezpośrednich problemów z tego powodu, ale nie korzystasz z przydatnej funkcji, więc otrzymujesz ostrzeżenie.

Answer 3

Według mojej wiedzy, COM nie miał na celu zapobiec piekłu w bibliotece DLL, to był dół samego Hadesu. Termin "DLL Hell" pochodzi od problemu wielu bibliotek, z których każda ma te same metody. Rejestracja zespołów COM w rejestrze systemu nie pomaga w rozdzielczości podczas uruchamiania.

Podpisanie zespołu, który ma działać jako serwer COM, zapewnia, że ​​zestaw nie koliduje z innymi złożonymi zestawami COM na tym samym komputerze. Bez podpisania, jeśli dwa zespoły zarejestrowane przez COM mają metody o tej samej nazwie, może to powodować problemy.