Dodałem słabo nazwany zestaw do mojego projektu Visual Studio 2005 (który jest mocno nazwany). Teraz pojawia się błąd:

„Zespół przywoływany„ xxxxxxxx ”nie ma mocnej nazwy”

Czy muszę podpisać to zgromadzenie strony trzeciej?

Aby uniknąć tego błędu, możesz:

• Załaduj zespół dynamicznie lub
• Podpisz zestaw zewnętrzny.

Instrukcje dotyczące podpisywania zestawów innych firm znajdują się w .NET-fu: Podpisywanie niepodpisanego zestawu (bez podpisywania z opóźnieniem) .

Podpisywanie zespołów innych firm

Podstawową zasadą podpisywania partii pragnącej jest

1. Zdemontuj zespół za pomocą ildasm.exei zapisz język pośredni (IL):

   ildasm /all /out=thirdPartyLib.il thirdPartyLib.dll 

2. Odbuduj i podpisz zestaw:

   ilasm /dll /key=myKey.snk thirdPartyLib.il

Naprawianie dodatkowych odniesień

Powyższe kroki działają poprawnie, chyba że zespół innej firmy ( A.dll ) odwołuje się do innej biblioteki ( B.dll ), która również musi zostać podpisana. Możesz zdemontować, odbudować i podpisać zarówno A.dll, jak i B.dll, używając powyższych poleceń, ale w czasie wykonywania ładowanie B.dll nie powiedzie się, ponieważ A.dll został pierwotnie zbudowany z odniesieniem do niepodpisanej wersji B.dll .

Rozwiązaniem tego problemu jest załatanie pliku IL wygenerowanego w kroku 1 powyżej. Musisz dodać token klucza publicznego B.dll do odwołania. Otrzymasz ten token dzwoniąc

sn -Tp B.dll 

co da ci następujące wyniki:

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.33440
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key (hash algorithm: sha1):
002400000480000094000000060200000024000052534131000400000100010093d86f6656eed3
b62780466e6ba30fd15d69a3918e4bbd75d3e9ca8baa5641955c86251ce1e5a83857c7f49288eb
4a0093b20aa9c7faae5184770108d9515905ddd82222514921fa81fff2ea565ae0e98cf66d3758
cb8b22c8efd729821518a76427b7ca1c979caa2d78404da3d44592badc194d05bfdd29b9b8120c
78effe92

Public key token is a8a7ed7203d87bc9

Ostatni wiersz zawiera token klucza publicznego. Następnie należy przeszukać IL A A.dll pod kątem odwołania do B.dll i dodać token w następujący sposób:

.assembly extern /*23000003*/ MyAssemblyName
{
  .publickeytoken = (A8 A7 ED 72 03 D8 7B C9 )                         
  .ver 10:0:0:0
}

Rozwiń plik projektu, który używa projektu, który nie ma „silnego klucza nazwy” i poszukaj .snkpliku (.StrongNameKey).

Przeglądaj do tego pliku w Eksploratorze Windows (tak, abyś wiedział, gdzie on jest).

Z powrotem w Visual Studio w projekcie, który nie ma „silnego klucza nazwy”, zrób

• Kliknij plik projektu prawym przyciskiem myszy
• Wybierz Właściwości
• Wybierz „kartę Podpisywanie” (po lewej)
• Kliknij pole wyboru „Podpisz zespół”
• Następnie <Browse>do .snkpliku, który znalazłeś wcześniej

To powinno wystarczyć. To rozwiązało problem dla jednego projektu, używając formularza w innym projekcie w tym samym rozwiązaniu.

Mam nadzieję, że to pomoże.

Szukałem rozwiązania tego samego problemu i odznaczenie opcji „Podpisz zespół” działa dla mnie:

(jak możesz zauważyć, zrzut ekranu pochodzi z VS2010, ale mam nadzieję, że komuś pomoże)

Napisałem narzędzie do automatycznego tworzenia silnych nazw zespołów, w tym tych, dla których nie masz kodu źródłowego lub projektów, które zostały porzucone. Wykorzystuje wiele technik opisanych w odpowiedziach w prosty sposób, bez żadnych wad lub wad istniejących narzędzi lub przestarzałych instrukcji.

http://brutaldev.com/post/2013/10/18/NET-Assembly-Strong-Name-Signer

Mam nadzieję, że pomoże to każdemu, kto musi podpisać zgromadzenie osoby trzeciej, bez konieczności przeskakiwania przez obręcze, aby się tam dostać.

Możesz używać niepodpisanych zespołów, jeśli twój zespół również jest niepodpisany.

Podpisanie zewnętrznego zespołu działało dla mnie:

http://www.codeproject.com/Tips/341645/Referenced-assembly-does-not-have-a-strong-name

EDYCJA : Dowiedziałem się, że pomocne jest publikowanie kroków na wypadek, gdyby linkowany artykuł nie był już ważny. Wszystkie podziękowania należą się Hiren Khirsaria :

1. Uruchom wiersz polecenia programu Visual Studio i przejdź do katalogu, w którym znajduje się biblioteka DLL.

   For Example my DLL is located in D:/hiren/Test.dll

2. Teraz utwórz plik IL za pomocą poniższego polecenia.

   D:/hiren> ildasm /all /out=Test.il Test.dll (to polecenie generuje bibliotekę kodów)

3. Wygeneruj nowy klucz do podpisania swojego projektu.

   D:/hiren> sn -k mykey.snk

4. Teraz podpisz bibliotekę za pomocą ilasmpolecenia.

   D:/hiren> ilasm /dll /key=mykey.snk Test.il

Jak podpisać niepodpisany zespół zewnętrzny

1. Otwórz wiersz polecenia programisty dla programu Visual Studio. To narzędzie jest dostępne w programach Windows i można je znaleźć przy użyciu domyślnego wyszukiwania w systemie Windows.
2. Upewnij się, że monit ma dostęp do następujących narzędzi, wykonując je raz: sn ildasmiilasm
3. Przejdź do folderu, w którym znajduje się plik Cool.Library.dll
4. sn –k Cool.Library.snk aby utworzyć nową parę kluczy
5. ildasm Cool.Library.dll /out:Cool.Library.il zdemontować bibliotekę
6. move Cool.Library.dll Cool.Library.unsigned.dll aby zachować oryginalną bibliotekę jako kopię zapasową
7. ilasm Cool.Library.il /dll /resource=Cool.Library.res /key=Cool.Library.snk złożyć bibliotekę o silnej nazwie
8. powershell -command "& {[System.Reflection.AssemblyName]::GetAssemblyName($args).FullName} Cool.Library.dll"aby uzyskać pełną nazwę zespołu. Potrzebujesz tego bitu, jeśli musisz odwoływać się do biblioteki DLL w zewnętrznych plikach konfiguracyjnych, takich jak web.config lub app.config.

Miałem ten problem z aplikacją o silnej nazwie, a następnie musiałem ją zmienić, aby odwoływał się do zespołu o niezbyt silnej nazwie, więc odznaczałem opcję „Podpisz zestaw” w sekcji podpisywania właściwości projektu, ale nadal narzekałem. Uznałem, że musiał to być artefakt, który powodował problem, ponieważ wszystko inne zrobiłem poprawnie i po prostu tak było. Znalazłem i usunąłem wiersz: [assembly: AssemblyKeyFile ("twoja_plik_pliku.snk")] z jego pliku assemblyInfo.cs. Potem nie będzie żadnych reklam kompilacji.

Działało mi się to z biblioteką dll ServiceStack, którą zainstalowałem z nuget. Okazuje się, że był dostępny inny zestaw bibliotek dll, które zostały oznaczone jako podpisane. Nie będzie to odpowiedź dla wszystkich, ale może być konieczne sprawdzenie istniejącej podpisanej wersji zestawu.

Dla mnie moim problemem było to, że miałem dwa takie same pakiety NuGet zainstalowane z różnymi wersjami.

Usunięcie zaznaczenia „Podpisz zespół” pod zakładką „Podpisywanie” działa tak, jak powiedział @Michal Stefanow.

Dodaj tutaj to najprostszy sposób na podpisanie własnych plików i / lub plików innych osób. Wystarczy dodać ten wiersz w wierszu polecenia „Zdarzenie po kompilacji”:

"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\signtool.exe" sign /f "$(ProjectDir)\YourPfxFileNameHere.pfx" /p YourPfxFilePasswordHere /d "Your software title here" /du http://www.yourWebsiteHere.com /t http://timestamp.verisign.com/scripts/timstamp.dll /v "$(BaseOutputPath)$(TargetFileName)"

Możesz podpisywać pliki innych osób lub własne pliki i dowolną ich liczbę.

Stare pytanie, ale jestem zaskoczony, że nikt jeszcze nie wspomniał o ilmerge. ilmerge jest od Microsoft, ale nie jest dostarczany z VS lub SDK. Możesz go pobrać stąd . Istnieje również repozytorium github . Możesz także zainstalować z nuget:

PM>Install-Package ilmerge

Używać:

ilmerge assembly.dll /keyfile:key.snk /out:assembly.dll /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /ndebug

W razie potrzeby możesz wygenerować własny plik klucza za pomocą sn (z VS):

sn -k key.snk

Sytuacja: Miałeś projekt A, B, C, D w roztworze X, Y

Projekt A, B, C w X Projekt A, C, D w Y

Potrzebuję użyć projektu C w projekcie A, ale później go nie używam. W bin Debug projekt A miał C.dll.

Jeśli skompiluję rozwiązanie X, wszystko dobrze (w tym rozwiązaniu usuwam odniesienie A -> C.), ale w rozwiązaniu Y dostaję ten problem.

Rozwiązaniem jest usunięcie C.dll w projekcie A bin Debug

Najpierw upewnij się, że wszystkie pakiety nuget są w tej samej wersji dla wszystkich projektów w twoim rozwiązaniu. np. nie chcesz, aby jeden projekt odwoływał się do NLog 4.0.0.0, a inny projekt odwoływał się do NLog 4.1.0.0. Następnie spróbuj ponownie zainstalować pakiety nuget za pomocą

Update-Package -reinstall

Miałem 3 zespoły stron trzecich, do których odwoływało się moje złożenie A, a tylko dwa zostały uwzględnione w Odsyłaczach przez mój zespół B, który również odwoływał się do A.

Brakujące odwołanie do zestawu innej firmy zostało dodane przez polecenie aktualizacji pakietu i błąd zniknął.