Ссылочный путь проекта в системе контроля версий? - PullRequest
Новая
       37

Ссылочный путь проекта в системе контроля версий?

9 голосов
/ 12 августа 2010

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

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

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

Я уже немного искал и, похоже, не могунайти способы сделать это.Кто-нибудь знает способ заставить ссылочный путь входить и выходить из sourcecontrol?

Мы говорим здесь о Visual Studio 2008 и TFS 2008.

Приветствия, Антон.

Ответы [ 3 ]

12 голосов
/ 13 августа 2010

Хорошо, я, кажется, немного прояснил голову после хорошего ночного сна, сделал логичный шаг, а именно выяснил, где именно хранится информация и как. Оказалось, что информация была сохранена в файле .user для проекта в папке проекта, и, как выяснилось, этот файл содержит mbsuild xml.

Затем я сделал то, что хотел:

  • Создайте опорный путь, как я и требовал, чтобы облегчить оба сценария без какой-либо работы.
  • Просмотр файла .user проекта
  • Скопируйте PropertyGroup, содержащую ReferencePath
  • Вставьте PropertyGroup во все необходимые проекты .csproj xml.
  • Перезагрузка и сборка.

Готово.

0 голосов
/ 12 августа 2010

Это довольно просто - мы делаем это в нашем магазине.

Сначала в рабочей области (с помощью проводника Windows перейдите в папку Solution), создайте папку.Мы называем это «ссылочные сборки».Отсюда, удалите все свои DLL.

Теперь, в Solution, добавьте новую папку, соответствующую папке, созданной в Windows Explorer.В эту папку добавьте все библиотеки DLL, которые вы только что добавили.

Наконец, в каждом проекте настройте ссылки для использования библиотек DLL, которые были добавлены в решение.

Теперь ссылки на ваш проектБиблиотеки DLL, являющиеся частью решения, поэтому при запуске сборки она будет извлекать DLL из Source Control для генерации сборки.

Кроме того, я бы порекомендовал вообще не использовать GAC, если вы можете избежатьЭто.По моему опыту, эталонное поведение странно.Кажется, что ссылки идут сначала в GAC, а затем в DLL в локальной папке, что означает, что если DLL обновляется, то используется библиотека GAC вместо DLL в локальной папке (которая, вероятно, является обновленной).

0 голосов
/ 12 августа 2010

Ссылки хранятся в файле * .csproj. Узлами являются ItemGroup / Reference ...

Thomas

...