2012-08-23 13 views
7

VS 2010, Windows Server 2003, .Net 3.5 soluzione, che sono stati migurated da Net 1.1SGEN: errore: Impossibile caricare il file o l'assembly (eccezione da HRESULT: 0x8013141A)

Tutti i progetti in soluzione sono Ritardo firmato . Il soluton può essere compilato con successo per Debug, ma fallisce sempre per il rilascio con il seguente errore. SGEN: errore: impossibile caricare il file o l'assemblaggio 'AssemblaggioX, Versione = 1.0.5000.0, Cultura = neutro, PublicKeyToken = xxxxxxxx' o una delle sue dipendenze. Convalida del nome non riuscita. (Eccezione da HRESULT: 0x8013141A)

Il AssemblaggioX è il progetto che voglio costruire. Tutte le DLL di riferimento di questo progetto vengono salvate nella cartella locale e firmate già. Se cambio la proprietà del progetto AssemblingX per firmarlo, allora la soluzione può essere costruita per il rilascio con successo.

ho creato uno sgen.exe.config per consentire "loadFromRemoteSources" seguendo le visite sul http://social.msdn.microsoft.com/Forums/nl-NL/msbuild/thread/695581ae-77e7-4c3a-bb3f-6472b8c47f65

Ma nulla è cambiato. Qualche idea?

Grazie

risposta

17

Questo problema è correlato alla convalida del nome sicuro. Apri il tuo AssemblyX in Ildasm.exe (C: \ Programmi (x86) \ Microsoft SDK \ Windows \ v7.0A \ bin). Nota il suo PublicKeyToken, diciamo pkt123 per un esempio. Ora aprire prompt dei comandi VS in modalità amministratore ed eseguire il comando sn.exe. Ad esempio:

sn -Vr *,pkt123 

Costruisci di nuovo la soluzione e tutto dovrebbe andare bene ora.

Ma se non si riceve lo stesso errore ora, è necessario eseguire una versione diversa di sn.exe. Per individuarlo, vai al prompt dei comandi di Visual Studio.

c:\Program Files(x86)>dir /s sn.exe 

Potrebbero essere necessari 5-10 secondi e fornire un elenco di file sn.exe. Vai al percorso ed esegui sn.exe, richiesto o che ti appartiene, come mostrato sopra. Se non sei sicuro di quale eseguire, esegui tutto il file sn.exe. Questo dovrebbe e deve risolvere il tuo problema. In caso contrario, fammi sapere e lasciami portare avanti il ​​RnD di nuovo.

+0

Soluzione eccezionale, grazie :) – Mark

+0

Grazie Mark .... :) – Sandy

+0

Lifesaver !! Grazie – mo13

3

Dal momento che non sono in grado di commentare l'unica risposta a questo, volevo essere sicuro che gli altri utenti che hanno trovato questa risposta non facessero gli stessi errori che altri potrebbero avere. In base alla documentazione MSDN per la potente utility di denominazione, l'utilizzo dello switch Vr (signature skipping) può causare il caricamento di assembly dannosi e deve essere utilizzato solo in DEVELOPMENT e non in deployment.

http://msdn.microsoft.com/en-us/library/k5b5tt23(v=vs.80).aspx

0

se non ancora risolto è necessario eliminare o impostare AllowStrongNameBypass (DWORD) su "1" nelle principali

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework 

a 64 bit computer,

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework 

e

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework 
1

Nel mio caso il motivo era che la libreria nativa è stata costruita in una cartella diversa dal resto dell'applicazione.

0

Aperto cmd.

Cd "C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin" 

Run:

sn –Vr **AssemblingX** name (without dll extension), **PublicKeyToken**

(il codice)

Ricostruire la soluzione. E dovrebbe essere risolto.

Problemi correlati