Dlaczego przekierowanie wiązania zestawu nie działa w mojej witrynie sieci Web?

Question

Mam projekt witryny sieci Web, które uruchamiam z Visual Studio przy użyciu wbudowanego serwera sieci web rozwoju. Wirtualnej ścieżki stronie jest ustawiona /

Web.config zawiera element wykonania z

<runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <dependentAssembly> 
     <assemblyIdentity name="CMS.Controls" publicKeyToken="834b12a258f213f9" culture="neutral" /> 
     <bindingRedirect oldVersion="4.1.3518.21577" newVersion="4.1.3561.21846" /> 
    </dependentAssembly> 
    </assemblyBinding> 
</runtime> 

już usunięte atrybut xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0" z korzenia configuration elementu.

Tutaj jest błąd:

Could not load file or assembly 'CMS.Controls, Version=4.1.3518.21577, Culture=neutral, PublicKeyToken=834b12a258f213f9' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Oto log wiązania:

The operation failed. 
Bind result: hr = 0x80131040. No description available. 
... 
LOG: DisplayName = CMS.Controls, Version=4.1.3518.21577, Culture=neutral, PublicKeyToken=834b12a258f213f9 
(Fully-specified) 
... 
LOG: This bind starts in default load context. 
LOG: Using application configuration file: D:\Project\WebSite\web.config 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config. 
LOG: Post-policy reference: CMS.Controls, Version=4.1.3518.21577, Culture=neutral, PublicKeyToken=834b12a258f213f9 
... 
LOG: Assembly Name is: CMS.Controls, Version=4.1.3561.21846, Culture=neutral, PublicKeyToken=834b12a258f213f9 
WRN: Comparing the assembly name resulted in the mismatch: Revision Number 

Wydaje mi się, jakby to ignorując moje przekierowanie. Patrzyłem na to przez godzinę, czy mam literówkę czy coś takiego?

Answer 1

Czy próbowałeś użyć FUSLOGVW.exe znalezionego w folderze bin SDK do instalacji Visual Studio? Daje to bardziej szczegółowe dane wyjściowe dotyczące błędów łączenia złożenia.

Plik manifestu, który nie pasuje do odwołania do zespołu, oznacza po prostu, że znaleziono nieprawidłowy zespół, ponieważ manifest jest metadanymi opisującymi złożenie i jego zawartość. Zauważyłem, że ta seria artykułów wyjaśniła mi bardzo wiele o tym, jak działają wiązania zespołów; .NET Assembly FAQ – Part 1

Answer 2

Czy to jest wydanie 64-bitowe/32-bitowe dll, czasami istnieją różne wersje biblioteki dll dla różnych systemów. Nawet jeśli używasz 64-bitowej wersji systemu Windows, serwer WWW dla programistów działa jako aplikacja 32-bitowa.

Po przełączeniu na serwer CassinDev można przełączyć się na serwer 64-bitowy. Działa to tak samo.

Answer 3

Ostatnio miałem podobny problem z używaniem dwóch wersji, więc wyczyściłem rozwiązanie i odbudowałem je ponownie. Również jeśli czyste nie wyczyściło plików z folderu bin, ręcznie usunąłem pliki i ponownie je skompilowałem. W zależności od wersji frameworku musimy wyczyścić pliki, dla .NET 4 tutaj jest folder, aby znaleźć pliki tymczasowe, gdzie stara wersja się cofa C: \ WINDOWS \ Microsoft.NET \ Framework \ v4.0.30319 \ Tymczasowa ASP Pliki .NET

Answer 4

Wiem, że minęło trochę czasu, ale może to pomoże komuś kiedyś ...

Mamy dokładnie ten sam problem na pewnym projekcie, to było webapplication a nie strona, ale jako problem troska odwołuje zespoły Nie sądzę różnica typu projektu jest istotnym elementem (może się mylę)

Powiedzmy mamy następujące zespoły:

• WebApplicationAssembly

  1. CMSControlAsse mbly
  2. UserManagementAssembly

WebApplicationAssembly odwołuje CMSControlAssembly i UserManagementAssembly.

Tak więc próbowaliśmy wykonać wiązanie zespołu na CMSControlAssembly, z takim samym sukcesem jak Ty.

Po niektóre kopania światła wymyślił:

rzeczą jest to, że użyliśmy webcontrols wewnątrz CMSControlAssembly bezpośrednio w naszym webapplication. (wiązanie zestawów zostało ustawione z myślą o tym)

Ale CMSControlAssembly był również przywoływany przez UserManagementAssembly, i to było przyczyną naszego problemu.

UserManagementAssembly został skompilowany przy użyciu niższej wersji CMSControlAssembly niż używana przez aplikację webową.

Ta niska wersja zespołu nigdzie nie została znaleziona przez aplikację internetową, ponieważ jedyną dostępną wersją była ta, której dotyczy wiązanie zespołu.

W rzeczywistości błąd nie pokazuje nieumiejętnego wiązania zespołu, ale brakuje zespołu dla UserManagementAssembly.

Answer 5

Jedynym powodem, który może wyjaśnić taki błąd, jest to, że nowa wersja nie jest wdrożona na GAC (w folderze z systemem Windows).

Important: Not deployed applies as well if the public key does not match between versions for example version 1 public key was abcd but new version uses efgh. Make sure public matches and that thew version is on the GAC.