Podczas sondowania złożeń, dlaczego szukany klucz publicznyKey różni się, gdy działa jako administrator kontra zwykły użytkownik?

Question

Mam instrukcje ze skoroszytu kursu Microsoft .Net 2006, przechodząc przez jedno z ćwiczeń. (W szczególności ten kurs to MS2349B i robię moduł 4 ćwiczenie 2). Ćwiczenia te wydają się być zbudowane na wcześniejsze dni Vista, kiedy wszyscy mają pełne uprawnienia administratora przez cały czas. (Używam .net 4.0.)

Ćwiczenie to polega na budowaniu mocnego zestawu nazw, instalowaniu go w GAC, budowaniu lokalnego pliku wykonywalnego na silnym zestawie nazwanym, sprawdzaniu, czy uruchamiany jest plik wykonywalny.

Zgodnie z samouczka podpisać mój zespół za pomocą #if bloku:

#if STRONG 
[assembly: System.Reflection.AssemblyVersion("2.0.0.0")] 
[assembly: System.Reflection.AssemblyKeyFile("OrgVerKey.snk")] 
#endif 

buduję mój plik wykonywalny jako użytkownik lokalny:

C:\path\to\lab>csc /define:STRONG /target:library 
/out:AReverser_v2.0.0.0\AReverser.dll AReverser_v2.0.0.0\AReverser.cs 
C:\path\to\lab>csc /reference:MyStringer\Stringer.dll  
/reference:AReverser_v2.0.0.0\AReverser.dll Client.cs 

zainstalować go w GAC poprzez wizualne wiersz poleceń modułu Studio uruchom jako administrator:

C:\path\to\lab>gacutil /i AReverser_v2.0.0.0\AReverser.dll 

Po uruchomieniu mojego exe w wierszu polecenia administratora I uzyskać wyjście, którego oczekuję - aplikacja działa poprawnie i wydaje się ładować bibliotekę poprawnie z gac. Kiedy biegnę pod non-admin wierszu polecenia I pojawia się następujący błąd

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembl 
y 'AReverser, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b5fcbdcff229fabb' 
or one of its dependencies. The located assembly's manifest definition does not 
match the assembly reference. (Exception from HRESULT: 0x80131040) 
    at MainApp.Main() 

Co dziwne dla mnie jest to, że TokenKluczaPublicznego nie jest takie samo jak to, co znajduje się w GAC:

AReverser, Version=2.0.0.0, Culture=neutral, PublicKeyToken=f0548c0027634b66 

ale gdybym odinstalować AReverser z GAC i próbować uruchomić mój exe jako administratora wierszu pojawia się następujący komunikat o błędzie, który wskazuje jej szuka oczekiwanego klucza publicznego tokena f0548c0027634b66:

C:\path\to\lab>gacutil /u "AReverser,Version=2.0.0.0,Culture=neutral, 
PublicKeyToken=f0548c0027634b66" 
Microsoft (R) .NET Global Assembly Cache Utility. Version 4.0.30319.1 
Copyright (c) Microsoft Corporation. All rights reserved. 


Assembly: AReverser, Version=2.0.0.0, Culture=neutral, PublicKeyToken=f0548c0027 
634b66 
Uninstalled: AReverser, Version=2.0.0.0, Culture=neutral, PublicKeyToken=f0548c0 
027634b66 
Number of assemblies uninstalled = 1 
Number of failures = 0 

C:\path\to\lab>Client.exe 

Unhandled Exception: System.IO.FileLoadException: Could not load file or assembl 
y 'AReverser, Version=2.0.0.0, Culture=neutral, PublicKeyToken=f0548c0027634b66' 
or one of its dependencies. The located assembly's manifest definition does not 
match the assembly reference. (Exception from HRESULT: 0x80131040) 
    at MainApp.Main() 

wezwania na mocy Administrator, faktycznie szuka właściwego klucza publicznegoKey.

Co daje? Dlaczego wyszukiwane dla publickKeyTokens różnią się? Co mogłem zrobić źle?

EDIT

Aplikacja config powiedziano nam korzystać mogą być sprawcy, zastanawiam się, czy trzeba być administratorem, aby zastosować niektóre z tych ustawień. Pozbycie się tego wydaje się powodować działanie jako administrator, który nie może się powieść (chociaż w tym przypadku publicKeyToken jest wymieniony jako NULL). Oto mój app config

<configuration> 
    <runtime> 
     <assemblyBinding 
      xmlns="urn:schemas-microsoft-com:asm.v1"> 
      <probing privatePath="MyStringer"/> 
      <publisherPolicy apply="no"/> 
      <dependentAssembly> 
       <assemblyIdentity name="AReverser" 
        publicKeyToken="f0548c0027634b66" 
        culture=""/> 
       <publisherPolicy apply="no"/> 
       <bindingRedirect oldVersion="2.0.0.0" 
        newVersion="2.0.0.0"/> 
      </dependentAssembly> 
     </assemblyBinding> 
    </runtime> 
</configuration> 

Answer 1

Szukaj dysk dla AReverser.dll. Możliwe, że masz jakieś dodatkowe kopie gdzieś ukryte. VS może tworzyć kopie w tle skompilowanych bibliotek dll.

Jeśli to nie pomaga w aktywowaniu rejestrowania fuzji (użyj dziennika fuslogvw.exe lub logi fuzji buforowej na dysku), a następnie zajrzyj do dzienników, z których jest ładowana problemowa biblioteka dll. IMO to jest niewłaściwa biblioteka dll, która jest ładowana.

Answer 2

Gdzie twoje rozwiązanie mówi, że montaż jest? Visual studio nie używa GAC ​​do zbudowania, więc jeśli masz inną wersję montowanego zestawu montażowego pozostawionego w twoim katalogu referencyjnym, klient zostanie zbudowany przeciwko temu i nie powiedzie się, gdy próbuje załadować w czasie wykonywania, ponieważ gac jest ładowany jako pierwszy .