Странное поведение при смешанной загрузке сборок с помощью Assembly.LoadFrom и Assembly.Load.
-
03-07-2019 - |
Вопрос
Странное поведение при смешанной загрузке сборок с помощью Assembly.LoadFrom и Assembly.Load.
Я столкнулся со странным поведением при загрузке сборок с помощью Assembly.LoadFrom, а затем с помощью Assembly.Load.
Я загружаю сборку с помощью Assembly.LoadFrom, где сборка находится в папке, которая не является папкой выполнения.
Позже в моем тестовом коде, когда я пытаюсь еще раз загрузить эту сборку с помощью Assembly.Load, загрузка завершается с ошибкой System.IO.FileNotFoundException («Не удалось загрузить файл или сборку…»), несмотря на то, что сборка уже загружена. .Загрузка завершается неудачей как со строгим, так и со нестрогим именем (исходная причина повторной загрузки этой сборки — использование BinaryFormatter).
Однако если сборка находится в папке выполнения, последующая загрузка будет успешной в обоих случаях, со строгим и нестрогим именем.В этом случае вы можете видеть, что две одинаковые сборки загружаются из двух разных мест.
Простой пример кода, воссоздающий эту проблему:
Сборка сборка1 = Сборка.LoadFrom(@"C:\a.dll");
// Загрузка с помощью сильного именного сбоя сборки сборки2 = сборка. Загрузка (@"A, версия = 1,0.0.0, культура = нейтральная, publickeyToken = 14986c3f172d1c2c");
// также загрузка с помощью непроницаемого сбоя сборки сборки3 = сборка. Загрузка (@"a");
- Любое объяснение, почему CLR игнорирует уже загруженную сборку?
- Есть идеи, как я могу облегчить эту проблему?
Спасибо.
Решение
Это не странно.Согласно документации, загрузка с помощью Load и LoadFrom поместит сборки в разные контексты. Этот может помочь.
- Любое объяснение, почему CLR игнорирует уже загруженную сборку?
Потому что они в другом контексте.
- Есть идеи, как я могу облегчить эту проблему?
Загрузите из того же контекста или помогите CLR найти сборку, возможно, присоединив обработчик к AppDomain.AssemblyResolve
.
Альтернатива
Если место, из которого вы загружаете сборки, является подпапкой AppDomain.BaseDirectory, вы можете просто добавить запись в свой App.config:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;bin2\subbin;bin3"/>
</assemblyBinding>
</runtime>
</configuration>
Другие советы
@Кент Бугарт:Кажется, это правильное объяснение.Для полного объяснения у Сюзанны Кук есть эта запись в блоге, которая содержит немного больше информации, чем исходная, которую вы опубликовали:http://blogs.msdn.com/suzcook/archive/2003/05/29/57143.aspx
Ниже приведен код, использующий AppDomain.AssemblyResolve.
// register to listen to all assembly resolving attempts:
AppDomain currentDomain = AppDomain.CurrentDomain;
currentDomain.AssemblyResolve += new ResolveEventHandler(MyResolveEventHandler);
// Check whether the desired assembly is already loaded
private static Assembly MyResolveEventHandler(object sender, ResolveEventArgs args) {
Assembly[] assemblies = AppDomain.CurrentDomain.GetAssemblies();
foreach (Assembly assembly in assemblies) {
AssemblyName assemblyName = assembly.GetName();
string desiredAssmebly = args.Name;
if (assemblyName.FullName == desiredAssmebly) {
return assembly;
}
}
// Failed to find the desired assembly
return null;
}