2012-10-25 12 views
8

Pobrałem najnowszy kod DotNetOpenAuth z GitHub i początkowo nie udało się go skompilować. Naprawiłem problem wykonując następujące czynności:DotNetOpenAuth kompiluje po modyfikacji, ale zgłasza wyjątek podczas wykonywania przykładowego projektu

sn -Vr *,2780ccd10d57b246 

znaleźć tutaj:

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

poszedł do przodu i zrobił kilka modyfikacji DotNetOpenAuth.AspNet projektu. Kompilacja była w porządku. Następnie utworzyłem projekt sieciowy MVC 4 w próbkach, aby przetestować moje zmiany. Rozwiązanie ponownie skompilowane. Jednak zaraz po kliknięciu opcji debugowania wyświetlany jest żółty ekran śmierci programu ASP.NET z następującym błędem:

Nie można załadować pliku lub zespołu "DotNetOpenAuth.AspNet" lub jednej z jego zależności. Nie można zweryfikować silnego podpisu nazwy. Zgromadzenie mogło zostać zmodyfikowane lub zostało podpisane z opóźnieniem, ale nie zostało w pełni podpisane za pomocą prawidłowego klucza prywatnego. (Wyjątek od HRESULT: 0x80131045)

Projekt MVC 4 został stworzony z pustego szablonu, więc nie ma odniesienia do Microsoft.Web.WebPages.OAuth

Co mi brakuje? Ukończyłem resztę schodów znajdujących się w linku powyżej:

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

a także zmodyfikowany plik \ Tools \ DotNetOpenAuth.props, a konkretnie linie: 27,29,30 z nowymi wartościami

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> 

Odpowiedz

6

Modyfikowanie pliku rekwizytów nie powinno być konieczne. Problem prawdopodobnie dotyczy komputera 64-bitowego, a polecenie sn, które zostało uruchomione, miało wpływ tylko na rejestr 32-bitowy. Następnie w czasie wykonywania kończy się niepowodzeniem, ponieważ uruchamiasz witrynę w rejestrze 64-bitowym, który nie zawiera wpisu weryfikacji pominięcia.

"Właściwy" sposób na to polega na zainstalowaniu 64-bitowego zestawu Windows SDK, aby uzyskać 64-bitowy plik sn.exe i uruchomienie tego polecenia. Jednak tutaj jest szybki i łatwy sposób:

Wyjazd wartość klucz reg: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\*,2780ccd10d57b246

i skopiować ten klucz nad do

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

Następnie uruchom ponownie wszystkie istotne procesy (MSBuild .exe, devenv.exe, iis, WebDAV, czy cokolwiek to jest hosting strony internetowej i zgłaszanie błędu). Powinno zacząć działać dla ciebie.

+0

dzięki! Walczyłem z tym od jakiegoś czasu. – epignosisx

+0

Miałem odwrotną sytuację: sn.exe dodał klucz do HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ StrongName \ Verification \, ale do IIS7 wpłynęła HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ StrongName \ Verification \. Dziękuję za odpowiedź! –

+0

Czy VS2015 korzysta z sn64 x86 lub x64? Ponieważ jednak powoduje błąd. Ale ulepszenie rejestru działa. – Legends

Powiązane problemy