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

У меня есть проект веб-сайта, который я запускаю из 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.

Вот ошибка:

Не удалось загрузить файл или сборку 'CMS.Controls, Version = 4.1.3518.21577, Culture = нейтрально, PublicKeyToken = 834b12a258f213f9 'или одной из его зависимостей. Расположенные определение манифеста сборки не соответствуют ссылочной позиции сборки. (Исключение из 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

Мне кажется, что он игнорирует мою переадресацию. Я смотрел на него в течение часа, у меня есть опечатка или что-то в этом роде?

Ответы

Ответ 1

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

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

Скажем, у нас есть следующие сборки:

  • WebApplicationAssembly

    • CMSControlAssembly
    • UserManagementAssembly

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

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

После некоторого рытья появились огни:

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

Единственная причина, которая может объяснить такую ​​ошибку, заключается в том, что новая версия не развертывается в GAC (в папке сборок Windows).

Важно: Не развертывается также, если открытый ключ не совпадает между версиями, например, открытым ключом версии 1 был abcd, но в новой версии используется efgh. Убедитесь, что общедоступные матчи и эта версия на GAC.

Ответ 5

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