2012-10-25 12 views
8

Ich habe den neuesten DotNetOpenAuth-Code von GitHub heruntergeladen und konnte anfangs nicht erstellt werden. Ich reparierte das Problem, indem Sie den folgenden ausgeführt wird:DotNetOpenAuth kompiliert nach den Änderungen, löst aber eine Laufzeitausnahme aus, wenn das Beispielprojekt ausgeführt wird.

sn -Vr *,2780ccd10d57b246 

hier:

http://www.dotnetopenauth.net/developers/contributing/quickstart-environment/

Ich ging weiter und habe einige Änderungen an dem Projekt DotNetOpenAuth.AspNet. Es kompiliert gut. Dann habe ich ein MVC 4 Webprojekt unter Samples erstellt, um meine Änderungen zu testen. Die Lösung wurde erneut kompiliert. Sobald ich aber auf Debug klicke, erhalte ich den gelben ASP.NET-Bildschirm mit dem folgenden Fehler:

Die Datei oder Baugruppe 'DotNetOpenAuth.AspNet' oder eine ihrer Abhängigkeiten konnte nicht geladen werden. Starke Namens-Signatur konnte nicht verifiziert werden. Möglicherweise wurde die Assembly manipuliert oder es wurde eine Verzögerung signiert, aber nicht vollständig mit dem richtigen privaten Schlüssel signiert. (Ausnahme von HRESULT: 0x80131045)

Das MVC-4-Projekt wurde von der leeren Vorlage erstellt, so gibt es keinen Hinweis auf Microsoft.Web.WebPages.OAuth

Was bin ich? Ich schloss die restlichen Schritte in dem obigen Link gefunden:

sn -k mykeyfile.pfx 
sn -i mykeyfile.pfx mykeycontainer 
sn -p mykeyfile.pfx mykeyfile.pub 
sn -q -t mykeyfile.pub 
sn -Vr *,<YourPublicKeyTokenHere> 

und verändern auch die Datei \ Tools \ DotNetOpenAuth.props, speziell die Zeilen: 27,29,30 mit den neuen Werten

26. <SignAssembly>true</SignAssembly> 
27. <PublicKeyFile Condition="'$(PublicKeyFile)' == ''">$(ProjectRoot)src\official-build-key.pub</PublicKeyFile> 
28. <AssemblyOriginatorKeyFile Condition="'$(AssemblyOriginatorKeyFile)' == ''">$(PublicKeyFile)</AssemblyOriginatorKeyFile> 
29. <KeyPairContainer Condition="'$(KeyPairContainer)' == ''">DotNetOpenAuth</KeyPairContainer> 
30. <PublicKeyToken>2780ccd10d57b246</PublicKeyToken> 
31. <DelaySign>true</DelaySign> 
32. <SignedSubPath>signed\</SignedSubPath> 

Antwort

6

Das Ändern der Requisiten-Datei sollte nicht notwendig sein. Das Problem liegt wahrscheinlich daran, dass Sie sich auf einem 64-Bit-Computer befinden und der von Ihnen ausgeführte Befehl sn nur die 32-Bit-Registrierung betrifft. Sie schlagen dann zur Laufzeit fehl, weil Sie die Website in der 64-Bit-Registrierung ausführen, in der der Eintrag zur Überprüfung der Überspringung nicht enthalten ist.

Der "richtige" Weg, es zu tun ist, das 64-Bit-Windows-SDK zu installieren, so dass Sie 64-Bit-sn.exe erhalten und diesen Befehl auch ausführen. Hier ist jedoch die schnelle und einfache Art und Weise:

Überprüfen Sie den Wert Ihrer reg Schlüssel aus: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\*,2780ccd10d57b246

und kopieren Sie die Schlüssel über

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\StrongName\Verification\*,2780ccd10d57b246

Dann werden alle relevanten Prozesse (MSBuild neu starten .exe, devenv.exe, iis, WebDAV oder was immer es ist, das Ihre Website hostet und den Fehler meldet). Es sollte für dich arbeiten.

+0

danke! Ich habe jetzt schon eine Weile damit zu kämpfen. – epignosisx

+0

Ich hatte eine entgegengesetzte Situation: sn.exe hinzugefügt Schlüssel zu HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ StrongName \ Verification \, aber IIS7 wurde von HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ StrongName \ Verification \ betroffen. Danke für die Antwort! –

+0

Verwendet VS2015 die x86 oder x64 sn.exe? Weil es trotzdem einen Fehler gibt. Aber die Registry Tweak funktioniert. – Legends

Verwandte Themen