Почему закрытое обнаружение сборок не использует имя полнофункциональной сборки для соответствия, а скорее имя файла?

Question

Наше приложение динамически загружает набор частных сборок, каждый из которых находится под их собственным подкаталогом. Каждый из них имеет свои собственные зависимости, которые также находятся в том же подкаталоге. Каждая сборка имеет строгое имя, а зависимости - это одна и та же библиотека, но разные версии.

MyApp 
|-> Folder1\ 
|   |->PrivateAssembly1.dll 
|   |->Dependency.dll     Version 1.0.0.0 
| 
|-> Folder2\ 
|   |->PrivateAssembly2.dll 
|   |->Dependency.dll     Version 2.0.0.0 
| 
... 

Поскольку мы развертываем xcopy, поэтому мы не используем GAC.

У нас также есть probing privatePath, определяемый для "Folder1;Folder2", чтобы решить любую проблему, не находя частные сборки.

Проблема заключается в том, что PrivateAssembly1.dll, похоже, находит свою зависимость, но PrivateAssembly2.dll этого не делает. Вернее, он пытается использовать Dependency.dll из Folder1 вместо Folder2.

Я знаю, что эти проблемы могут быть разрешены вручную с использованием события AssemblyResolve, однако это не самый чистый подход. Есть ли другие решения, которые я рассматриваю?

Спасибо за любые идеи.

Update:

Выход инструмента Fusion Log:

LOG: DisplayName = Dependency, Version=1.0.0.0, Culture=neutral, PublicKeyToken=######### 
(Fully-specified) 
LOG: Appbase = file:///C:/Workspaces/Shell/MyApp/bin/ 
LOG: Initial PrivatePath = NULL 
LOG: Dynamic Base = NULL 
LOG: Cache Base = NULL 
LOG: AppName = NULL 
... 
LOG: Attempting download of new URL file:///C:/Workspaces/Shell/MyApp/bin/Dependency.DLL. 
LOG: Attempting download of new URL file:///C:/Workspaces/Shell/MyApp/bin/Dependency/Dependency.DLL. 
LOG: Attempting download of new URL file:///C:/Workspaces/Shell/MyApp/bin/Folder2/Dependency.DLL. 
LOG: Assembly download was successful. Attempting setup of file: C:\Workspaces\Shell\MyApp\bin\Folder2\Dependency.dll 
LOG: Entering run-from-source setup phase. 
LOG: Assembly Name is: Dependency, Version=2.0.0.0, Culture=neutral, PublicKeyToken=####### 
WRN: Comparing the assembly name resulted in the mismatch: Major Version 
ERR: The assembly reference did not match the assembly definition found. 
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated. 

Так в основном, это находит Dependency.dll в Folder2, пытается загрузить его только увидеть, что версия не совпадение. Я бы предположил, что бы попробовать Folder1 рядом, но он просто останавливается там ...

Answer 1

Первое, что нужно сделать, это использовать Fusion Log Viewer «FUSLOGVW.exe» включить протоколирование сборочного нагрузки. Это покажет вам, где CLR пытается загрузить зависимости. Это должно подтвердить, что в каком-то месте отсутствует — и сообщите, что вам не хватает в .config.

[Edit: Теперь журнал]

После того, как имя сборки соответствия не было найдено, не более (файл) поиск происходит. То есть сохраните уникальные имена сборки.

(Это похоже ++ перегруженных метод C, первый лучший матч найден, а затем доступность проверяется, так что более слабый матч параметр, который доступен не будет рассматриваться.)

NB. Если вы работаете на 64-битной системе, вы можете разделить 32 и 64-битные версии этого инструмента: убедитесь, что вы используете правильный.

Answer 2

Причина, по которой объекты .NET относятся к этому, заключается в том, что вы пытаетесь загрузить разные версии одной и той же сборки в приложение. Вы должны решить, можете ли вы разрешить PrivateAssembly1.dll и PrivateAssembly2.dll использовать одну и ту же версию библиотеки. Это сэкономит вам массу неприятностей, если это возможно.

Действительно, вы можете заставить обе версии Dependency.dll загрузиться в ваш appdomain, добавив настраиваемый распознаватель, который загружает его, но имейте в виду, что вы вводите довольно узкий путь, если вы это сделаете. Например, в обеих версиях будут разные версии любых статических переменных, а также типы, созданные в сборке Folder1 \ Dependency.dll, не будут распознаны Folder2 \ Dependency.dll, и наоборот, хотя типы могут показаться «одинаковыми».