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>
danke! Ich habe jetzt schon eine Weile damit zu kämpfen. – epignosisx
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! –
Verwendet VS2015 die x86 oder x64 sn.exe? Weil es trotzdem einen Fehler gibt. Aber die Registry Tweak funktioniert. – Legends