Связывание сборки.NET. Как и почему (1.1, 2.0, GAC, файлы политик и многое другое...)

Question

Я работал над множеством очень "странных" проблем с некоторыми версиями DLL, файлами политики и элементами в GAC, и за всю свою жизнь я не смог найти надежного ответа на вопрос, как / почему.NET Framework выбирает сборки, которые он делает, при привязке ссылок проекта.

Прежде всего, чтобы рассказать немного о том, что у нас есть, у нас есть два DLL-файла библиотеки со следующей информацией.

ApplicationAssembly.dll - .NET 1.1 code - .dll Version 01.01.00.1234
ApplicationAssembly.dll - .NET 1.1 code - .dll Version 01.01.00.1244
ApplicationAssembly.dll - .NET 2.0 code - .dll Version 02.00.00.1111

Каждая из этих сборок загружается в GAC, и каждая из версий 1.1 и 2.0 имеет файл политики, определяющий самую последнюю версию для загрузки.

У нас есть проект, который ссылается на версию файла ApplicationAssembly.dll версии 1.1.00.1234, однако проект был перемещен, и путь к подсказке больше не действителен. Тем не менее, ссылка не является мертвой, но она показывает версию 02.00.00.1111, а не предполагаемую версию 1.1 сборки.

Как определяется этот процесс, и почему он сразу перешел на платформу 2.0? Если мы укажем, что это ссылка "Определенная версия", даже при неправильном пути подсказки будет найдена правильная DLL, но из-за будущего риска поломки мы не сможем оставить этот параметр включенным.

Я думаю, вопрос в том, почему это происходит? И как.NET определяет, куда идти для сборки?

Answer 1

Правила, которые Fusion (функция управляемой загрузки dll в.Net) использует для определения местонахождения dll, довольно обширны (из-за того, что Gac/ строгие имена / пользовательские хуки загрузки указывают лишь на некоторые).

Официальные правила рассматриваются в общих чертах здесь. Поскольку ваша библиотека имеет сильное имя, применяются более сложные правила.