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

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

2 голосов
/ 07 октября 2009

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

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, однако это не самый чистый подход. Есть ли другие решения, которые я пропускаю?

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

Обновление:

Вывод инструмента 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 дальше, но это просто останавливается там ...

Ответы [ 2 ]

1 голос
/ 07 октября 2009

Первое, что нужно сделать, это использовать Fusion Log Viewer "FUSLOGVW.exe" 1 , чтобы включить ведение журнала загрузки сборки. Это покажет вам, откуда CLR пытается загрузить зависимости. Это должно подтвердить, что в каком-то месте отсутствует & mdash; и сказать, чего вам не хватает в вашем .config.

[Редактировать: теперь с журналом]

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

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

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

0 голосов
/ 07 октября 2009

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

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

...