Библиотеки DLL с автоматическим управлением версиями в Visual Studio 2008

мы пытаемся разобраться в некоторых соглашениях по обработке зависимостей с кодом, зарегистрированным в svn. предыдущий метод был в основном бесплатным для всех, то есть проекты нельзя было проверить и построить без возни со ссылками (большинство проектов написаны на C#).

мы исправляем это шаг за шагом и теперь проверяем двоичные файлы в отдельном репозитории svn. сборки отличаются номером версии svn, которому они соответствуют, поэтому у вас может быть путь, например svnrelease/libraryA/r1000/libraryA.dll. одна вещь, которая возникла, - это такой сценарий: библиотека A зависит от библиотеки B, проект P зависит от библиотеки A, но также напрямую ссылается на библиотеку B. что, если библиотека A ссылается на ревизию 1000 B, но прямая ссылка проекта P на ревизия 2000?

Я предложил включать номер версии в имена файлов DLL, когда они проверяются в репозитории релизов svn, чтобы несколько версий могли сосуществовать. коллега предположил, что VS2k8 может автоматически справиться с этим. поэтому, если в проекте библиотеки A вы установите его как версию 1.8, VS называет вывод «libraryAsvnrelease/libraryA/r1000/libraryA.dll8.dll», а в проекте P вы можете иметь ссылку на «$ (выпуск) \ библиотека \ $ (версия)», который это может решить. Я не мог найти никакой информации о том, как это сделать. Это возможно? и если нет, разумен ли мой метод включения имени версии в двоичный файл DLL?

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


person toasteroven    schedule 19.10.2009    source источник


Ответы (1)


Обычно я позволяю каждому проекту (или чаще каждому решению) иметь каталог «lib», в котором я размещаю сборки, от которых зависит решение. Это означает, что каждое решение не зависит от других решений. Ну, по крайней мере вроде; зависимости внутри каждого каталога lib по-прежнему должны хорошо сочетаться друг с другом. Но это дает ситуацию, когда каждое решение можно обновлять отдельно, не нарушая работу других решений.

person Fredrik Mörk    schedule 19.10.2009