Почему перенаправление сборок привязки не работает на моем веб-сайте?

Question

У меня есть проект веб-сайта, который я запускаю из Visual Studio с помощью встроенного веб-сервера разработки. Виртуальный путь веб-сайта установлен в /

web.config содержит во время выполнения элемента с

<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> 

Я уже удален атрибут xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0" из корневого configuration элемента.

Здесь ошибка:

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)

Вот журнал связывания:

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 

Кажется мне, как он игнорирует мой редирект. Я смотрел на него в течение часа, у меня есть опечатка или что-то еще?

Answer 1

Вы пытались использовать FUSLOGVW.exe в папке SDK bin для установки Visual Studio? Это дает более подробный вывод для сбоев привязки сборки.

Показатель, не соответствующий ссылке на сборку, в основном означает, что он обнаружил неправильную сборку, поскольку манифест представляет собой метаданные, которые описывают сборку и ее содержимое. Я обнаружил, что эта серия статей объясняет мне многое о том, как работают привязки к сборке; .NET Assembly FAQ – Part 1

Answer 2

Является ли это 64-битной/32-разрядной DLL-версией, иногда существуют разные сборки dll для разных систем. Даже если вы используете 64-битную версию Windows, веб-сервер разработки работает как 32-битное приложение.

При переключении на сервер CassinDev вы можете переключиться на 64-битный сервер. Он работает одинаково.

Answer 3

Недавно у меня была аналогичная проблема с использованием двух версий, поэтому я очистил решение и снова переработал, и он работал иногда. Также, если очистка не очистила файлы из папки bin, я удалил файлы вручную и снова построил. В зависимости от версии рамки нам нужно очистить файлы, для .net 4 здесь находится папка для поиска временных файлов, где старая версия отступает C: \ WINDOWS \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP .NET-файлы

Answer 4

Я знаю, что это было какое-то время, но, возможно, это может кому-то помочь ...

Мы получили точно такую ​​же проблему на каком-то проекте, это было WebApplication, а не сайт, а как проблема относится ссылки сборка я не думаю, что разница типа проекта имеет отношения (я могу ошибаться)

Допустим, мы имеем следующие узлы:

• WebApplicationAssembly

  1. CMSControlAsse mbly
  2. UserManagementAssembly

WebApplicationAssembly ссылается CMSControlAssembly и UserManagementAssembly.

Итак, мы попытались выполнить сборку на CMSControlAssembly с таким же большим успехом, как и вы.

Через некоторое рытье зажегся свет:

дело в том, что мы использовали WebControls внутри CMSControlAssembly непосредственно в нашем WebApplication. (сборка была установлена ​​с учетом этого)

Но CMSControlAssembly также ссылалась на UserManagementAssembly, и это стало причиной нашей проблемы.

UserManagementAssembly был скомпилирован с более низкой версией CMSControlAssembly, чем тот, который используется веб-приложением.

Эта нижняя версия сборки нигде не была найдена с помощью web-приложения, поскольку единственной версией была та, которая была предназначена для сборщика.

Так что на самом деле ошибка не показывает функциональную сборку, но сборка отсутствует для UserManagementAssembly.

Answer 5

Единственная причина, которая может объяснить такую ​​ошибку, заключается в том, что новая версия не развернута на GAC (в папке сборок 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.