Ho aggiunto un assembly con un nome debole al mio progetto Visual Studio 2005 (che è fortemente chiamato). Ora sto ricevendo l'errore:

"L'assembly di riferimento" xxxxxxxx "non ha un nome sicuro"

Devo firmare questa assemblea di terze parti?

Per evitare questo errore è possibile:

• Caricare il gruppo in modo dinamico oppure
• Firma l'assemblea di terze parti.

Le istruzioni per la firma di assembly di terze parti sono disponibili in .NET-fu: Firma di un assembly non firmato (senza firma ritardata) .

Firma di assemblee di terze parti

Il principio di base per firmare una festa della sete è

1. Disassemblare il gruppo usando ildasm.exee salvare la lingua intermedia (IL):

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

2. Ricreare e firmare l'assembly:

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

Correzione di riferimenti aggiuntivi

I passaggi precedenti funzionano correttamente a meno che l'assembly di terzi ( A.dll ) non faccia riferimento a un'altra libreria ( B.dll ) che deve essere firmata. È possibile disassemblare, ricostruire e firmare sia A.dll che B.dll utilizzando i comandi sopra, ma in fase di esecuzione il caricamento di B.dll fallirà perché A.dll è stato originariamente creato con un riferimento alla versione non firmata di B.dll .

La soluzione a questo problema è correggere il file IL generato nel passaggio 1 sopra. Sarà necessario aggiungere il token della chiave pubblica di B.dll al riferimento. Ottieni questo token chiamando

sn -Tp B.dll 

che ti darà il seguente output:

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

L'ultima riga contiene il token della chiave pubblica. È quindi necessario cercare nell'IL di A.dll il riferimento a B.dll e aggiungere il token come segue:

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

Espandere il file di progetto che utilizza il progetto che non ha "una chiave con nome .snksicuro " e cercare il file (.StrongNameKey).

Sfoglia questo file in Esplora risorse (solo per sapere dove si trova).

Torna in Visual Studio nel progetto che non "ha una chiave con nome sicuro", fallo

• Fare clic con il tasto destro sul file di progetto
• Seleziona Proprietà
• Seleziona "Scheda Firma" (a sinistra)
• Fare clic sulla casella di controllo "Firma l'assieme"
• Quindi <Browse>al .snkfile che hai trovato in precedenza

Questo dovrebbe fare il trucco. Ciò ha risolto un problema per me per un progetto utilizzando un modulo all'interno di un altro progetto nella stessa soluzione.

Spero possa essere d'aiuto.

Stavo cercando una soluzione allo stesso problema e deselezionando l'opzione "Firma l'assemblaggio" funziona per me:

(come noterai lo screenshot proviene da VS2010 ma spero che possa aiutare qualcuno)

Ho scritto uno strumento per assegnare automaticamente nomi di insegne di segni, compresi quelli per i quali non si dispone del codice sorgente o di progetti che sono stati abbandonati. Utilizza molte delle tecniche descritte nelle risposte in modo semplice senza difetti o svantaggi di strumenti esistenti o istruzioni datate.

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

Spero che questo aiuti chiunque abbia bisogno di firmare un'assemblea di terze parti senza dover saltare attraverso i cerchi per arrivarci.

È possibile utilizzare assembly non firmati se anche il assembly è senza segno.

La firma dell'assemblea di terze parti ha funzionato per me:

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

EDIT : ho imparato che è utile pubblicare passaggi nel caso in cui l'articolo collegato non sia più valido. Tutto il merito va a Hiren Khirsaria :

1. Esegui il prompt dei comandi di Visual Studio e vai alla directory in cui si trova la tua DLL.

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

2. Ora crea il file IL usando il comando qui sotto.

   D:/hiren> ildasm /all /out=Test.il Test.dll (questo comando genera la libreria di codici)

3. Genera nuova chiave per firmare il tuo progetto.

   D:/hiren> sn -k mykey.snk

4. Ora firma la tua libreria usando il ilasmcomando.

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

Come firmare un assembly di terze parti senza segno

1. Apri il prompt dei comandi per sviluppatori per Visual Studio. Questo strumento è disponibile nei programmi Windows e può essere trovato utilizzando la ricerca di Windows predefinita.
2. Assicurati che il tuo prompt abbia accesso ai seguenti strumenti eseguendoli una volta: sn ildasmeilasm
3. Passare alla cartella in cui si trova Cool.Library.dll
4. sn –k Cool.Library.snk per creare una nuova coppia di chiavi
5. ildasm Cool.Library.dll /out:Cool.Library.il per smontare la biblioteca
6. move Cool.Library.dll Cool.Library.unsigned.dll per mantenere la libreria originale come backup
7. ilasm Cool.Library.il /dll /resource=Cool.Library.res /key=Cool.Library.snk per riassemblare la biblioteca con un nome sicuro
8. powershell -command "& {[System.Reflection.AssemblyName]::GetAssemblyName($args).FullName} Cool.Library.dll"per ottenere il nome completo dell'assembly. Sarà necessario questo bit se si deve fare riferimento alla DLL in file di configurazione esterni come web.config o app.config.

Ho riscontrato questo problema per un'app che aveva un nome sicuro, quindi ho dovuto cambiarlo per fare riferimento a un assembly con un nome non forte, quindi ho deselezionato "Firma l'assembly" nella sezione Firma delle proprietà del progetto ma mi sono comunque lamentato. Ho pensato che dovesse essere un artefatto da qualche parte a causare il problema dato che ho fatto tutto il resto correttamente ed era proprio quello. Ho trovato e rimosso la riga: [assembly: AssemblyKeyFile ("yourkeyfilename.snk")] dal suo file assemblyInfo.cs. Quindi nessun reclamo in seguito.

Mi stavo imbattendo in questo con una dll ServiceStack che avevo installato con nuget. Si scopre che c'era un altro set di dll disponibili che erano etichettati firmati. Non sarà la risposta per tutti, ma potrebbe essere necessario verificare la presenza di una versione firmata esistente dell'assembly.

Per me il mio problema era che avevo due degli stessi pacchetti NuGet installati con versioni diverse.

Rimozione del segno di spunta "Firma l'assieme" sotto "Firma" scheda funziona come ha detto @Michal Stefanow.

Aggiungi qui è il modo più semplice per firmare i tuoi file e / o i file di altre persone. Devi solo aggiungere questa riga nella "Riga di comando dell'evento post-build":

"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)"

Puoi firmare i file di altre persone o i tuoi file e quanti ne vuoi.

Vecchia domanda, ma sono sorpreso che nessuno abbia ancora menzionato ilmerge. ilmerge proviene da Microsoft, ma non viene fornito con VS o SDK. Puoi scaricarlo da qui però. C'è anche un repository github . Puoi anche installare da nuget:

PM>Install-Package ilmerge

Usare:

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

Se necessario, puoi generare il tuo file di chiavi usando sn (da VS):

sn -k key.snk

Situazione: avevi il progetto A, B, C, D nella soluzione X, Y

Progetto A, B, C in X Progetto A, C, D in Y

Ho bisogno di usare il progetto C nel progetto A, ma in seguito non lo uso. Nel bin Il progetto di debug A aveva C.dll.

Se compilo la soluzione X, tutto bene (in questa soluzione elimino il riferimento A -> C.), ma nella soluzione Y ottengo questo problema.

La soluzione è eliminare C.dll nel progetto A bin Debug

Per prima cosa assicurati che tutti i pacchetti nuget siano nella stessa versione per tutti i progetti nella tua soluzione. ad esempio, non si desidera che un progetto faccia riferimento a NLog 4.0.0.0 e un altro progetto faccia riferimento a NLog 4.1.0.0. Quindi prova a reinstallare i pacchetti nuget con

Update-Package -reinstall

Avevo 3 assiemi di terze parti a cui faceva riferimento il mio assemblaggio A e solo 2 erano inclusi in Riferimenti dal mio assemblaggio B che faceva anche riferimento a A.

Il riferimento mancante all'assembly di terze parti è stato aggiunto dal comando del pacchetto di aggiornamento e l'errore è scomparso.