В каком порядке выполняется поиск мест для загрузки ссылочных библиотек DLL?
Я знаю, что платформа .NET ищет ссылочные библиотеки DLL в нескольких местах.
- Глобальный кеш сборок (GAC)
- Любые частные пути, добавленные в домен приложений.
- Текущий каталог исполняемой сборки
В каком порядке производится поиск в этих местах? Прекращается ли поиск DLL, если найдено совпадение, или он продолжается во всех местах (и если да, то как разрешаются конфликты)?
Кроме того, подтвердите или отклоните эти местоположения и укажите любые другие местоположения, которые я не упомянул.
Ответы 3
«При загрузке библиотек DLL поиск в текущем каталоге больше не выполняется! Это изменение также было внесено в Windows XP SP1. Теперь по умолчанию сначала выполняется поиск во всех системных расположениях, затем в текущем каталоге и, наконец, во всех заданных пользователем путях. "
(ref. http://weblogs.asp.net/pwilson/archive/2003/06/24/9214.aspx)
The default serach order, which can be changed by the application, is also described on MSDN: http://msdn.microsoft.com/en-us/library/ms682586.aspx
Я обнаружил, что статья ссылается на статью MSDN на Порядок поиска DLL, в которой говорится
For managed code dependencies, the Global Assembly Cache always prevails; the local assembly in application directory will not be picked up if there is an existing (or newer with policy) copy in the GAC.
Учитывая это, я полагаю, что список MSDN верен с одним дополнением
0. Global assembly cache
статьи больше не существует, поэтому мы понятия не имеем, что остальная часть списка основана на вашем ответе
На моем конце все ссылки в порядке.
Загрузка сборки - довольно сложный процесс, который зависит от множества различных факторов, таких как файлы конфигурации, политики издателя, настройки домена приложения, хосты CLR, частичные или полные имена сборок и т. д.
Простая версия состоит в том, что сначала идет GAC, а затем - частные пути. % PATH% никогда не используется.
Лучше всего использовать Средство просмотра журнала привязки сборки (Fuslogvw.exe) для отладки любых проблем с загрузкой сборки.
РЕДАКТИРОВАТЬhttp://msdn.microsoft.com/en-us/library/aa720133.aspx объясняет процесс более подробно.
У меня нет реальных проблем с загрузкой сборки. Я пытаюсь понять порядок поиска / загрузки с академической точки зрения.
И вы правы насчет "% path%" ... Я ошибся, когда работал с вызовами p / invoke (я использовал "% path%", чтобы упростить использование "DllImportAttribute").
Если .net dll ссылается на родную dll, пути могут быть использованы
Кажется, это зависит от загрузки обычной Dll, а не сборки .net.