Понимание управления версиями DLL в .NET 1.1 по сравнению с .NET 3.5

Question

По-разному ли реализовано управление версиями в .NET 1.1 по сравнению с .NET 3.5? Кажется, что я могу смешивать и сопоставлять более старые и новые версии зависимых dll в развернутых приложениях, используя .NET 1.1, но приводит к проблемам при выполнении того же самого смешивания, совпадающего с dll, работающим в развернутых приложениях .NET 3.5.

Answer 1

Многое из этого зависит от свойства «useSpecificVersion», которое может быть установлено по вашей ссылке. Общее правило заключается в том, что вы можете использовать НОВУЮ версию ссылочной библиотеки DLL, но не более старую версию.

Если для «UseSpecificVersion» задано значение true, это заставит приложение использовать эту версию и ТОЛЬКО ту версию указанной библиотеки DLL. Эта функция была в .NET все время.

Пример использования конкретной версии

Если вы соберете dll X со ссылкой на версию 01.01.00.00 Ссылочной сборки Y. Любое использование с версией, отличной от 01.01.00.00 сборки Y, приведет к ошибке.

Стандартный пример

Если вы создаете dll X со ссылкой на версию 01.01.00.00 Ссылочной сборки Y, вы можете использовать версию 01.01.00.00 или более позднюю без проблем.

• 01.01.00.00 - Работы
• 01.01.01.00 - Работы
• 01.05.00.00 - Работы
• 01.00.01.00 - Сбой, так как это предыдущая версия.

Answer 2

Возможно, я неправильно понял ответ продавца Mitchel, но, похоже, он неверно полагает, что такое «useSpecificVersion».Я обновил свою память с помощью нескольких простых тестов, но они нацелены на .net 3.5, так как я не могу нацелиться на 1.1 в VS2010.

Похоже, что люди считают, что установив «useSpecificVersion» в сетке свойствVisual Studio .NET RUNTIME позволяет заменять библиотеки DLL на более новые версии сборок ... Это неверно.

Ничто (исключая привязку пользовательской сборки) не изменит тот факт, что если ваша «зависимость» будет строго названа, _that_exact_version_ должно присутствовать в приложении во время выполнения, иначе вы получите исключения, относящиеся к ассемблеру не найден / type-load-exception.

"useSpecificVersion" - это просто опция времени компиляции.Это позволяет Visual Studio заменить данную DLL, чтобы гарантировать, что она может разрешать ссылки для успешной компиляции.Он активно используется для многоцелевых возможностей Visual Studio.

Просто для того, чтобы дать вам простой пример ...

Обратите внимание на то, как если вы добавите ссылку project нанекоторые DLL, вы не получаете опцию 'useSpecificVersion' в вашей сетке свойств - это потому, что вы указали явный проект.Однако, если вы добавляете ссылку из диалогового окна «Добавить ссылки», то вы говорите: «добавьте ссылку, предоставленную из какого-либо установленного продукта ».Тогда у вас есть возможность установить «useSpecificVersion» в false.

Предположим, вы установили NLog 1.0 через MSI и поместили NLog.dll в диалог добавления ссылок (это делается с помощьюзапись в реестре).Если для 'useSpecificVersion' установлено значение False, то вы удаляете NLog.msi (версия 1.0), который удаляет DLL с вашего жесткого диска, Visual Studio на некоторое время будет жаловаться, поставив восклицательный знак на ссылку (вы должны ОЧИСТИТЬхотя проект, или VS просто возьмет DLL из вашей папки сборки).Но, поскольку ссылка была сохранена в файле проекта с параметром «useSpecificVersion false», если затем установить NLog.msi (версия 2.0) ... и перестроить (может потребоваться перезапустить VS), Visual Studio найдет версию 2NLog dll, и будьте вполне довольны его использованием - маленький желтый восклицательный знак исчезнет.Это работает в обоих направлениях, от более высоких номеров версий, до более низких и от более низких к более высоким.Если оставить для «useSpecificVersion» значение «True», Visual Studio не сможет выполнить эту замену.

Как вы можете видеть, это поведение не имеет ничего общего с тем, что происходит во время выполнения ... .NET по-прежнему ожидает EXACTверсия (если вы не настроили какое-либо перенаправление версии сборки в app.config), против которой она была скомпилирована.

Сохранение «useSpecificVersion» в качестве «True» гарантирует, что разработчик должен иметь правильную версию зависимостибиблиотеки, установленные в их системе, чтобы получить успешную сборку.

Мы используем библиотеки DevExpress, из которых часто выпускаются более новые версии, и мы никогда не хотели бы, чтобы «useSpecificVersion False» использовалось в их ссылках, потому что мы должны убедиться, чтокаждый разработчик имеет правильную версию DevExpress, установленную, когда они работают над продуктом.Без этого они могли бы непреднамеренно начать использовать функции DevExpress, которые либо устарели (из-за установки более старой версии), либо еще не были представлены (из-за более новой версии) в версии, которую мы фактически собираемся развернуть.

Answer 3

Не думаю, что это действительно изменилось, но вы можете прочитать об этом в MSDN .

Вы не можете смешивать и сочетать более старые и новые версии, потому что более старые будут проблемой.

Скажем, у вас есть:

abc.exe 1.0, который также ссылается на XYZ.DLL и ZZZ.DLL 1.0.

Если вы перекомпилируете ZZZ.DLL и сделаете его 1.1, abc.exe должен продолжить работу и загрузит DLL, если она присутствует в пути загрузки.

Однако, если вы скопируете ZZZ.DLL v0.9, abc.exe не сможет загрузить эту библиотеку, потому что она старше.

Имейте в виду, что если XYZ.DLL также имеет ссылки на ZZZ.DLL, то применяются те же правила.

С другой стороны, вы всегда можете установить DLLS в GAC и иметь разные доступные версии. Таким образом, когда вы загружаете сборку, если она находится в GAC, .NET попытается найти «правильную», но откажется от всего, что может использовать, если это более высокая версия.