2008-10-09 2 views
13

У нас есть несколько общих библиотек. В идеале мы хотим, чтобы они все использовать последнюю версию библиотеки DLL, даже если они были составлены на старой другой версии (предположим, что последняя версия имеет обратную совместимость)Visual Studio Ссылки и версии - как это работает?

например, мы имеем:

длл Проект
Общие управления Dll
дллы Logging
доступ к базе данных длл

проекта и общие элементы управления ссылкой v2 из DLL базы данных. Однако протоколирование ссылок v1.

Если разные версии указаны в разных компонентах, как VS выбирает, какой из них использовать?
Нужно ли перекомпилировать v1 dll для использования последней базы данных (v2) или мы можем получить это автоматически?
Можно ли использовать конкретную версию для использования?

Спасибо,

Alex

ответ

11

По умолчанию для версированных библиотек DLL Я считаю, что VS заставит точное совпадение. Однако, если вы посмотрите в свойствах ссылки, вы найдете свойство «Специфическая версия». Установите значение «false», и оно будет соответствовать более поздним версиям.

У меня нет полной версии VS со мной, чтобы найти подходящую ссылку MSDN, к сожалению.

Кроме того, вы можете использовать элемент assemblyBinding в app.config.

+0

Спасибо за сборку Ссылки на ссылку, но не можете найти это свойство конкретной версии vs2008 для проекта веб-сайта? – alexmac 2008-10-09 11:09:13

1

Если у вас есть источник, вы можете использовать ссылки на проекты вместо ссылок на dll. Таким образом, вы всегда будете получать последние.

5

Я наткнулся на этот сайт, который имеет несколько предложений: http://blog.fredrikhaglund.se/blog/2008/02/23/get-control-over-your-assembly-dependencies/

Чтобы получить конкретную версию вы, видимо, редактировать web.config или app.config?

«Наконец, посмотрите на свой файл csproj с помощью блокнота (или выгрузите проект в Visual Studio, чтобы он мог открыть его как текст). Когда вы добавляете ссылки с помощью Visual Studio, вы получите ссылку на сборку с обеих версий номер и открытый ключ, и это может дать вам некоторые проблемы при обновлении сборки поставщика до более новой версии ».
http://blog.fredrikhaglund.se/blog/2008/02/23/get-control-over-your-assembly-dependencies/

8

Здесь есть два сценария - использование сильных имен/GAC или использование сильных имен.

Если вы используете сильные имена и устанавливаете компоненты в GAC, тогда .Net захочет использовать версию компонента, которую клиент ссылался при компиляции. Таким образом, в вашем примере было бы вполне возможно, что Project будет ссылаться на базу данных V2, тогда как Logging ссылается на базу данных V1, поскольку библиотеки DLL могут храниться параллельно в GAC. Поэтому, если вы действительно хотите, чтобы Logging использовал V2 вместо V1, вам нужно будет изменить файлы конфигурации, чтобы сказать, что «ссылка на V1 должна быть указана на V2». Для этого есть разные места: файл приложения, машинный файл и т. Д.

Если вы не используете сильные имена, то.По умолчанию Net будет использовать версию DLL, находящуюся в той же папке, что и клиент. Предположим, что вы развертываете Project, CommonControls и Logging в той же папке, что и база данных V2. Тогда даже если Logging был создан против базы данных V1, он попытается использовать компонент в той же папке, то есть в базе данных V2. Пока V2 может предоставлять те же общедоступные классы и методы, которые Logging хочет использовать, он будет работать нормально.

В моей среде, где все наши приложения являются внутренними, мы не используем GAC. Мы просто разворачиваем все файлы, необходимые для приложения, в одну папку. Когда у вас много общих компонентов, просто будет кошмаром, чтобы синхронизировать файлы конфигурации.

Все это очень сильно отличается от COM, где все приложения загружают зарегистрированную в настоящий момент копию DLL (при условии, что V1 и V2 совместимы с бинарными).

Смежные вопросы