Dlaczego warto używać silnych nazwanych zestawów?

107

Jakie są zalety używania silnych nazwanych zestawów?

Czego nie można zrobić przy normalnym montażu?

c# .net

— deweloper
źródło

92

Pozwól mi najpierw wymienić zalety silnego nazwania twojego zespołu:

Silne nazewnictwo zestawu umożliwia dołączenie zestawu do globalnej pamięci podręcznej zestawów (GAC). W ten sposób umożliwia udostępnianie go w wielu aplikacjach.
Silne nazewnictwo gwarantuje unikatową nazwę dla tego zestawu. Dlatego nikt inny nie może używać tej samej nazwy zestawu.
Silna nazwa chroni rodowód wersji zestawu. Silna nazwa może zapewnić, że nikt nie będzie w stanie utworzyć kolejnej wersji zestawu. Użytkownicy aplikacji mają pewność, że wersja zestawu, którą ładują, pochodzi od tego samego wydawcy, który utworzył wersję, na której została zbudowana aplikacja.

Więcej informacji na temat silnego nazewnictwa firmy Microsoft można znaleźć w artykule Zestawy o silnych nazwach ( MSDN ).

— Kyle Rosendo
źródło

1

Czy na pewno w punkcie 4? Myślę, że może to zachowanie ostatnio się zmieniło. Próbowałem spowodować niepowodzenie ładowania zestawu o silnej nazwie, modyfikując go, ale ładował się on bez incydentów.

— Jens

19

W odniesieniu do punktu 4 jest to niepoprawne. Nie jest przeznaczony do ochrony przed manipulacją. Więcej informacji na blogs.msdn.com/b/shawnfa/archive/2005/12/13/… .

— Colin Bowern

1

@ RobV8R 90% naszych zależności to open source, klucze prywatne znajdują się w publicznych repozytoriach git (zgodnie z zaleceniami firmy Microsoft) i są dostępne dla każdego, kto ich chce.

— trampster

1

@ RobV8R Nie możesz użyć tutaj skompromitowanego słowa, które sugerowałoby, że ma ono być przede wszystkim tajemnicą. Wytyczne firmy Microsoft mówią, że klucz prywatny powinien być przechowywany w publicznym repozytorium źródeł. Klucze prywatne nie są zagrożone, są celowo publikowane. Biorąc pod uwagę, że klucze prywatne są znane i przeznaczone do użytku przez osoby modyfikujące kod open source projektów nadrzędnych (w przeciwnym razie licencja byłaby naruszona w wielu przypadkach), ludzie robiąc to używaliby innego numeru wersji, ale tego samego klucza, w tym na wypadek, gdyby wymagane było przekierowanie wiążące.

— trampster

1

@ RobV8R Pierwotnie miałem do czynienia z tym, że wiele osób wierzy, że silne nazewnictwo gwarantuje, że twoja zależność jest zablokowana do określonej wersji zestawu, a tak po prostu nie jest, proste przekierowanie powiązania może zmienić używaną wersję, pod warunkiem, że tak jest został podpisany tym samym kluczem prywatnym. I jak powiedziałem, klucze prywatne są celowo publikowane dla większości naszych zależności.

— trampster

9

Czego nie można zrobić przy normalnym montażu?

Ponieważ wszystkie dyskusje, które rozpoczęły się wraz z pojawieniem się Nugeta, sugerowały całkowite pozbycie się silnie nazwanych zestawów, moja firma próbowała tego i natrafiła na znaczącą zmianę zachowania, jeśli chodzi o ustawienia aplikacji:

Jeśli używasz automatycznych ustawień aplikacji lub aplikacji z zakresem użytkownika dostarczonych przez VisualStudio (dziedziczenie System.Configuration.ApplicationSettingsBase), wówczas silny plik EXE utworzy dokładnie 1 katalog w% LOCALAPPDATA% o nazwie na przykład „YourApplication.exe_StrongName_kjsdfzsuzdfiuzgpoisdiufzsdouif” usytuowany.

Ale bez silnej nazwy lokalizacja (= ścieżka) EXE zostanie użyta do utworzenia wartości skrótu, która już różni się między wersjami DEBUG i RELEASE, tworząc wiele katalogów wewnątrz% LOCALAPPDATA% nazwanych jak „YourApplication.exe_Url_dfg8778d6fs7g6d7f8g69sdf”. To sprawia, że nie można go używać w przypadku wdrożeń ClickOnce, w których katalog instalacyjny zmienia się przy każdej aktualizacji.

— springy76
źródło

5

Dodam, że bez silnej nazwy nie można używać przekierowań wiążących w plikach konfiguracyjnych.

To nie zadziała:

  <dependentAssembly>
    <assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="null" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
  </dependentAssembly>

Musisz mieć token klucza publicznego

  <dependentAssembly>
    <assemblyIdentity name="MyAssembly.MyComponent" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-2.0.0.0" newVersion="2.0.0.0" />
  </dependentAssembly>

— tomasat
źródło

9

Wiążące przekierowania nie są potrzebne, jeśli nie masz silnej nazwy.

— trampster

0

Oto przykład: chciałbym udzielić odpowiedzi kładąc większy nacisk na bezpieczeństwo . W przypadku, gdy tworzymy zestawy z kodem źródłowym, którego nie chcemy ponownie wykorzystać dla strony trzeciej, ale chcemy, aby był testowalny, możemy silnie podpisać zestaw i sprawić, by elementy wewnętrzne były widoczne tylko dla tych zestawów z ten sam podpis.

— Ricky Youssef
źródło