Ссылки на Visual Studio и управление версиями - как это работает?

У нас есть несколько общих библиотек. В идеале мы хотим, чтобы все они использовали последнюю версию dll, даже если они были скомпилированы против более старой версии (предположим, что последняя версия имеет обратную совместимость)

например, у нас есть:

Проект dll
Общие элементы управления dll
Ведение журнала dll
Доступ к базе данных dll

Ссылка на проект и общий контроль v2 базы данных dll. Однако протоколирование ссылок v1.

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

Спасибо,

Алекс

Ответ 1

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

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

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

Ответ 2

Здесь есть два сценария: использование сильных имен /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 совместимы с бинарными).

Ответ 3

Я наткнулся на этот сайт, у которого есть несколько предложений: 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/

Ответ 4

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