Путь TeamCity к внешним ссылочным сборкам - PullRequest
Новая
       20

Путь TeamCity к внешним ссылочным сборкам

4 голосов
/ 13 октября 2009

Я работал над настройкой TeamCity, и у меня почти все работает, за исключением возможности компилировать решения VS2005, которые ссылаются на сборки, находящиеся вне пути решения. У меня есть SVN-репозиторий, структурированный следующим образом 

    Root
        Libraries
        Project 1
            Trunk
        Project 2
            Trunk

Проект 1 и Проект 2 ссылаются на сторонние сборки, расположенные в библиотеках. Это прекрасно работает в среде IDE VS2005 и при вызове MSBuild для файлов решения, поскольку HintPath для всех ссылок выглядит следующим образом: 

..\..\..\Libraries\ThirdParty.dll

Проблема, с которой я столкнулся, состоит в том, что, когда TeamCity умирает извлечение из SVN для Проекта 1 или Проекта 2, он помещает все во внутренние каталоги, которые не соответствуют структуре относительного пути, заданного HintPath.

Как мне это прояснить, либо через конфигурацию TeamCity, либо по-другому настроить мою структуру решений / каталогов? Любой из них будет работать для моих нужд.

Спасибо!

Ответы [ 3 ]

4 голосов
/ 21 октября 2009

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

0 голосов
/ 20 октября 2016

Что я сделал, так это установил VCS ROOT проекта в каталог верхнего уровня («Root» в соответствии со структурой вашего проекта). И отключил проект по умолчанию vcs root, созданный teamcity. После этого вы можете создать пользовательский шаг сборки, указав здесь свое решение «Путь к файлу решения: *» в типе сборки «Visual Studio (sln)». Теперь он правильно обрабатывает ссылки на библиотеки.

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

0 голосов
/ 13 октября 2009

Мы настроили сетевой каталог со всеми нашими сторонними dll. Затем мы сопоставили каталог с диском.

Таким образом, dll не были частью наших решений, и все проекты просто вызывают z: \ 3rdParty \ example.dll, чтобы получить сборки.

Кто-то из моей команды на самом деле настроил нашу команду, так что я могу совершенно ошибиться относительно того, как проблема была на самом деле решена или если у нас даже была эта проблема изначально:)

...