#.net #version
#.net #версия
Вопрос:
Я пытаюсь проанализировать проблему, при которой сборка assembly динамически загружается во время выполнения с использованием
Assembly.loadFrom("filePath")
в какой-то DLL myDLL1. Та же СБОРКА была статически связана с другой библиотекой DLL myDLL2 в том же решении, и есть вызовы к обеим библиотекам DLL из решения, скажем, myExecutable. Это работает нормально, если в папке, в которой развернуто решение, найдена точно такая же СБОРКА. СБОРКА имеет, скажем, версию .Net 1.0.1.1 и версию файла 1.0.1.7
Теперь был опубликован новый файл версии 1.0.1.8 СБОРКИ, который имеет точно такой же.Сетевая версия 1.0.1.1 как версия файла 1.0.1.7 СБОРКИ. Сборки имеют строгие имена, и маркер открытого ключа разных версий файлов также отличается. Первый вопрос: разумно ли это?
Если я помещаю новую файловую версию сборки в папку, в которой развернуто решение, я теперь получаю сообщение об ошибке. Я предполагаю, что это потому, что.Net runtime недоволен токеном открытого ключа, который не соответствует ожиданиям в соответствии с манифестом myDLL1, может ли кто-нибудь подтвердить это предположение?
Вывод fuslogvw с именами, адаптированными к описанию примера, выглядит следующим образом:
Assembly Binder Log Entry (11.11.2011 @ 13:38:52)
The operation failed.
Bind result: hr = 0x80070002. The system cannot find the file specified.
Assembly manager loaded from: C:WindowsMicrosoft.NETFrameworkv2.0.50727mscorwks.dll
Running under executable myExecutable
--- A detailed error log follows.
=== Pre-bind state information ===
LOG: User = xxxxx
LOG: DisplayName = ASSEMBLY (Partial)
LOG: Appbase = (folder the solution is deployed to)
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = NULL
Calling assembly : myDLL1, Version=2.1.2.0, Culture=neutral, PublicKeyToken=.....
===
LOG: Start binding of native image ASSEMBLY, Version=1.0.1.1, Culture=neutral, PublicKeyToken=xxxxxxxx.
LOG: IL assembly loaded from ASSEMBLY.
WRN: No matching native image found.
LOG: Bind to native image assembly did not succeed. Use IL image.
Я попытался использовать перенаправление привязки к версии 1.0.1.1 сначала с токеном открытого ключа из файла сборки версии 1.0.1.8, созданного sn -Tp, а также с
токен открытого ключа для сборки из информации манифеста myDLL1, соответствующей версии файла 1.0.1.7, но я получаю ту же ошибку. Я также добавил информацию о перенаправлении в конфигурацию myExecutable.
Затем я попытался использовать перенаправление привязки к версии 1.0.1.2 с токеном открытого ключа более новой версии ASSEMBLY. Загружается новая версия файла, но затем я получаю, конечно, несоответствие редакции.
Кто-нибудь может сказать мне, как использовать новую файловую версию ASSEMBLY в этой настройке без необходимости заменять все решение, статически связанное с новой версией файла, которая, конечно, работает?
TIA и наилучшие пожелания,
Thomas
Комментарии:
1. Мне кажется, вы подписали новую сборку другим ключом. Не очень хорошо, токен открытого ключа не должен отличаться.
2. Привет, Ганс. Нет, я не подписывал, старая и новая сборки являются сторонними. И да, новая версия имеет то же самое . сетевая версия, но новый токен открытого ключа. Мой вопрос, сформулированный немного по-другому: предполагая, что я действительно доверяю новой файловой версии сборки, потому что я уверен, что она из того же источника, скажем, есть ли какой-либо способ, например, с использованием файлов конфигурации, использовать ее без перекомпиляции всего приложения.
3. Пожалуйста, улучшите заголовок вашего вопроса, чтобы он был менее расплывчатым. В противном случае люди с подобной проблемой в будущем не смогут ее найти.
Ответ №1:
Хорошо, проведя еще несколько исследований и экспериментов, я теперь могу сам ответить на свой вопрос. Вот что я нашел:
-
The .Net framework откажется загружать сборку для приложения, если сборка не подписана тем же ключом, который был у сборки, с которым приложение было статически связано во время компиляции. Кажется, это невозможно изменить с помощью файла application.config или файла machine.config, хотя я не смог найти доказательства этого в документации. Подумав об этом некоторое время, я думаю, что это разумное поведение, поскольку оно отчасти доказывает, что пользователь приложения работает с той же сборкой, которую использовал разработчик.
-
Теперь я уверен, что 1) является правильным, в следующем: если ключ остается одинаковым для разных версий сборки, то перенаправление привязки отлично работает для этих версий. Это верно как для повторной привязки с использованием файла application.config, так и для файла machine.config.
Однако эти же файлы конфигурации перестают работать, как только сборка подписывается другим ключом. Неприятная вещь в этом случае заключается в том, что журнал, созданный fuslogvw, сообщает вам, что привязка не удалась по какой-либо другой причине (например, незначительное несоответствие номера версии). Он не жалуется на неправильный токен открытого ключа.
Другая неприятная вещь заключается в том, что вы можете добавить токен открытого ключа в качестве атрибута к XML-тегу в файлах конфигурации, что с самого начала привело меня по ложному пути. Я не знаю, почему открытый ключ может или должен быть добавлен в файлы конфигурации, поскольку .Net может извлекать эту информацию из двоичного файла сборки и приложения.
Я не знаю, можно ли изменить поведение, описанное в 1), путем изменения файла security.config .Net Framework. (Хотя даже если бы это можно было изменить таким образом, это, вероятно, создало бы риски для безопасности, которые я бы не хотел создавать на своем ПК).