2012-08-23 2 views
7

VS 2010 gewinnen Server 2003, .NET 3.5-Lösung, die von .Net 1.1SGEN: Fehler: Konnte nicht Datei oder Assembly (Ausnahme von HRESULT: 0x8013141A) laden

alle Projekte in Lösung migurated wurden, sind Verzögerung unterzeichnet . Die Lösung kann erfolgreich für den Debug-Modus erstellt werden, ist jedoch immer mit dem folgenden Fehler fehlgeschlagen. SGEN: Fehler: Datei oder Assembly konnte nicht geladen werden 'AssemblingX, Version = 1.0.5000.0, Culture = neutral, PublicKeyToken = xxxxxxxx' oder eine seiner Abhängigkeiten. Starke Namensvalidierung fehlgeschlagen. (Ausnahme von HRESULT: 0x8013141A)

Die AssemblingX ist das Projekt, das ich erstellen möchte. Alle referenzierten DLLs dieses Projekts werden im lokalen Ordner gespeichert und bereits signiert. Wenn ich die Eigenschaft des Projekts AssemblingX ändere, um es zu signieren, dann kann die Lösung für die Freigabe erfolgreich erstellt werden.

habe ich eine sgen.exe.config „loadFromRemoteSources“ zu ermöglichen, indem die http://social.msdn.microsoft.com/Forums/nl-NL/msbuild/thread/695581ae-77e7-4c3a-bb3f-6472b8c47f65

geführte folgende Aber nichts geändert. Irgendwelche Ideen?

Danke

Antwort

17

Dieses Problem hängt mit der starken Namensvalidierung zusammen. Öffnen Sie AssemblyX in Ildasm.exe (C: \ Programme (x86) \ Microsoft SDKs \ Windows \ v7.0A \ bin). Beachten Sie die PublicKeyToken, sagen wir pkt123 für ein Beispiel. Öffnen Sie jetzt die VS-Eingabeaufforderung im Administratormodus, und führen Sie den Befehl "sn.exe" aus. Wie zum Beispiel:

sn -Vr *,pkt123 

Ihre Lösung baut wieder und alles soll jetzt in Ordnung sein.

Aber wenn nicht und Sie erhalten denselben Fehler jetzt auch, dann müssen Sie eine andere Version von sn.exe ausführen. Wechseln Sie zu der Visual Studio-Eingabeaufforderung, um das zu finden.

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

Es 5-10 Sekunden dauern kann und sollte eine Liste von sn.exe Dateien geben. Gehe zum Pfad und führe die sn.exe aus, die benötigt wird oder dir gehört, wie oben gezeigt. Wenn Sie nicht sicher sind, welche ausgeführt werden soll, führen Sie alle sn.exe aus. Das sollte und muss Ihr Problem lösen. Wenn nicht, lassen Sie es mich wissen und lassen Sie mich den RnD erneut vortragen.

+0

Tolle Lösung, Danke :) – Mark

+0

Danke Mark .... :) – Sandy

+0

Lebensretter! Vielen Dank – mo13

3

Da ich nicht in der Lage bin, die einzige Antwort auf diese Frage zu kommentieren, wollte ich sicherstellen, dass andere Benutzer, die auf diese Antwort kamen, nicht die gleichen Fehler machen, die andere haben können. Gemäß der MSDN-Dokumentation für das Dienstprogramm für starke Benennungen kann die Verwendung des Vr-Schalters (Signature Skipping) dazu führen, dass bösartige Assemblys geladen werden, und sollte nur in DEVELOPMENT-Implementierungen verwendet werden.

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

0

wenn noch nicht behoben Sie müssen oder AllowStrongNameBypass (DWORD) gesetzt löschen auf "1" in den Schlüssel

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework 

Auf 64-Bit-Computern

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework 

und

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework 
1

In meinem Fall war der Grund, dass die native Bibliothek in anderen Ordner als der Rest der Anwendung erstellt wurde.

0

Öffnen cmd.

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

Run:

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

(der Code)

die Lösung neu erstellen. Und es sollte gelöst werden.