У меня есть проект ASP.NET с подключаемой архитектурой. У меня есть строго названная зависимость dll в моей цепочке ссылок, от которой зависят и приложение, и плагин. Я действительно хотел бы иметь возможность использовать некоторые старые плагины, которые были скомпилированы с более старой версией dll-зависимости, когда приложение обновляется новой dll-зависимостью.
В настоящее время, когда я вызываю Assembly.GetTypes (), я получаю ReflectionTypeLoadException с 5 исключениями LoaderException типа FileLoadException, все жалуются на одну и ту же dll. (В системе гораздо больше библиотек с сильными и слабыми именами, возможно, цепочки зависимостей вызывают дублирование в LoaderExceptions?)
https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/redirect-assembly-versions
Я попытался добавить в свой файл web.config.
<runtime>
<assemblyBinding>
<dependentAssembly>
<assemblyIdentity name="Common.Production"
publicKeyToken="0e80e12b03b04a71"
culture="en-us" />
<bindingRedirect oldVersion="2.0.0.1459" newVersion="2.0.0.1463" />
</dependentAssembly>
Но я все еще получаю ту же ошибку. Я попытался добавить все строго типизированные dll, о которых я знаю, в дерево зависимостей, без изменений в сообщении об ошибке или количестве LoaderExceptions.
IL DASM показывает, что у меня правильный ключ и версия, хотя он использует немного другой синтаксис:
.assembly extern Common.Production
{
.publickeytoken = (0E 80 E1 2B 03 B0 4A 71 ) // ...+..Jq
.ver 2:0:0:1459
}
Мой журнал содержит следующую информацию о загрузчике:
LOG: Using application configuration file: ...\web.config
LOG: Using host configuration file:
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: Common.Production, Version=2.0.0.1459, Culture=neutral, PublicKeyToken=0e80e12b03b04a71
...
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.
возможно ли игнорировать несоответствие манифеста сборки?
Если ключ подписи изменился, bindingRedirect не будет работать. Другой компонент, созданный на основе более новой версии (проверен в IL DASM, использует тот же токен открытого ключа. Он не изменился:
.assembly extern Common.Production
{
.publickeytoken = (0E 80 E1 2B 03 B0 4A 71 ) // ...+..Jq
.ver 2:0:0:1463
}
https://msdn.microsoft.com/en-us/library/ms973843.aspx
- Мы не хотим хранить dll в GAC, мы хотим, чтобы плагины использовали последнюю версию библиотеки.
- Версия политики, уже пытались реализовать как указано выше. Попытка расширить диапазон политики для конкретного приложения до
oldVersion="0.0.0.0-2.0.0.1459" No Publisher Policy. Политика машины не затрагивает эту сборку.
- .NET Framework Инструмент настройки? Я не смог найти это на своей машине.
https://stackoverflow.com/a/7889272/2091951
Может быть? Звучит рискованно? В сборке, которой я не пользуюсь, не должно быть типов, похоже, это укусит меня позже.
http://code.fitness/post/2016/12/assembly-binding-redirect.html
- попытался изменить на
culture="neutral", попытался удалить culture
- Возможно, проблема связана с цепочкой зависимостей. Я уже включил всех четырех возможных виновников в app.config. Как мне найти виновника?
Есть ли решение, открытое для меня, кроме перекомпиляции зависимости с удалением подписи и повторным выпуском всех плагинов, перекомпилированных без строго названной ссылки? Ни у кого в отделе (включая одного бывшего члена) нет веских причин для того, почему эта библиотека была строго названа, но у нас есть причины не желать перекомпилировать плагины.
Не удалось загрузить файл или сборку или одну из ее зависимостей
- Я не получаю никаких результатов от FusLogvw, и да, я включил ключ реестра и перезапустил. Информация, которую я получаю в своем журнале log4net, довольно полна, она показывает обработку файлов конфигурации и причину сбоя, но я не понимаю, почему элементы web.config не применяются.
Справочные ссылки: