Путь ссылки проекта в управлении исходным кодом?
во время разработки нашего приложения мы используем переходящую структуру и в то время как мы разрабатываем другую команду, использует более ранние сборки нашего программного обеспечения для создания содержания с ним.
Для упрощения легкого свопинга между сборками и командами, я надеялся использовать пустой Hintpaths в csproj файлах проектов содержания так, чтобы они могли использовать установленные блоки нашего GAC, чтобы создать против и тем временем добавить ссылочный путь к проектам для нашего использования во время разработки и циклов испытаний, где мы не хотим блоков, установленных в GAC.
Однако кажется, что ссылочные пути не хранятся в csproj файле и таким образом не получают sourcecontrolled. С тех пор будет обширное ветвление, это были бы меньше, чем идеал для устанавливания всех ссылочных путей снова, когда разработчик вытягивает другое ответвление от sourcecontrol.
Я искал немного теперь и, может казаться, не нахожу способы сделать это. Кто-либо знает о способе вызвать ссылочный путь в и из sourcecontrol?
Мы говорим Visual Studio 2008 и 2008 TFS здесь.
С наилучшими пожеланиями, Anton.
3 ответа
Хорошо, мне кажется, что после хорошего ночного сна у меня в голове немного прояснилось, я сделал логичный шаг, а именно выяснил, где именно и как хранилась информация. Оказалось, что информация хранилась в файле .user проекта в папке проекта, и, как выяснилось, этот файл содержит mbsuild xml.
Затем я сделал то, что хотел, а именно:
- Создайте эталонный путь, так как я требовал, чтобы он упростил оба сценария без какой-либо работы.
- Перейдите к файлу .user проекта.
- Скопируйте PropertyGroup, содержащую ReferencePath
- Вставьте PropertyGroup во все необходимые проекты .csproj xml.
- Перезагрузите и соберите.
Готово.
Ссылки хранятся в файле * .csproj. Узлами являются ItemGroup / Reference ...
Thomas
Это довольно просто - мы делаем это в нашем магазине.
Сначала в рабочей области (используя проводник Windows, перейдите в папку Solution) создайте папку. Назовем ее "Referenced Assemblies". Сюда поместите все ваши библиотеки DLL.
Теперь в Solution добавьте новую папку, соответствующую той, что была создана в проводнике Windows. В эту папку добавьте все DLL, которые вы только что бросили.
Наконец, в каждом проекте настройте ссылки на использование DLL, добавленных в решение.
Теперь ваш проект ссылается на DLL, которые являются частью решения, так что при запуске сборки он будет брать DLL из Source Control для создания сборки.
Кроме того, я бы рекомендовал вообще не использовать GAC, если вы можете этого избежать. По моему опыту, поведение ссылок странное. Похоже, что ссылки сначала идут в GAC, а затем на DLL в локальной папке, что означает, что если DLL обновляется, то используется та, что в GAC, а не DLL в локальной папке (которая, скорее всего, обновлена).