Использование NuGet для внутренних и внешних зависимостей в TFS

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

Итак, мой вопрос: как мне справиться с этим сценарием, в котором мне нужно получить свои зависимости с разных серверов?

Есть ли лучший способ справиться с внутренними зависимостями? Как все остальные это делают?

Также в качестве примечания я намерен использовать NuGet без передачи пакетов в TFS. Я планировал использовать схему метода в этой статье:

http://blog.davidebbo.com/2011/08/easy-way-to-set-up-nuget-to-restore.html


tfs version-control nuget nuget-server tfsbuild
person Cole W    schedule 07.10.2011    source источник

Ответы (2)


arrow_upward
11
arrow_downward

Рад, что вы изучаете сценарий без фиксации для пакетов NuGet в TFS. Вы можете взглянуть на мой пост в блоге на эту тему, где я объясняю концепцию.

EDIT (2012/06/13): NuGetPowerTools заменен встроенной функцией восстановления пакетов NuGet. Однако по-прежнему применяется та же концепция изменения элемента PackageSources в nuget.targets.

Вам определенно стоит взглянуть на NuGetPowerTools Дэвида Фаулера. После установки этого пакета вы можете включить команду Enable-PackageRestore (недавно установленная команда в консоли диспетчера пакетов), которая добавит... Включение восстановления пакета добавит цели MSBuild в файлы вашего проекта. Эти целевые объекты MSBuild запускают nuget.exe на этапе перед сборкой и извлекают все пакеты, необходимые для вашего проекта. Нет необходимости регистрировать пакеты NuGet в системе управления версиями, все, что вам нужно, — это packages.config и эти задачи msbuild.

Чтобы настроить несколько разных источников пакетов, необходимо задать некоторые параметры, которые будут использоваться этими задачами MSBuild. Один из них — PackageSources. Вы можете установить его, отредактировав файл NuGet.targets, который вы найдете в папке .nuget после включения восстановления пакета.

Что касается этих источников пакетов, вы можете настроить разные внутренние галереи NuGet или просто настроить разные общие сетевые ресурсы для использования. Это вопрос требований и предпочтений, так что вы можете выбирать. Все, что вам нужно сделать, это указать вашим целям msbuild использовать эти источники пакетов. Порядок, в котором вы их определяете, будет также порядком поиска пакетов.

Удачи! Ксавье

person Xavier Decoster    schedule 07.10.2011
comment
+1 Я попробую это. Спасибо за отзыв. Вы сейчас используете эту стратегию? - person Cole W; 07.10.2011
comment
Пожалуйста! Да. Это только потребительская часть истории, о которой вы просили. Существуют также способы автоматического создания пакетов после сборки. - person Xavier Decoster; 07.10.2011
comment
Поэтому, когда вы хотите отладить одну из ваших внутренних dll из проекта, в котором есть пакет nuget для этого, вы просто меняете свою ссылку, чтобы указать на отладочную версию, или настройки отладки вашего проекта каким-то образом вытягивают зависимости отладки? Это один из недостатков, которые я вижу в такой системе. - person Cole W; 07.10.2011
comment
Хороший вопрос! Выход есть, поскольку вы используете TFS со встроенным сервером символов. Если ваши внутренние библиотеки DLL публикуют свои символы на сервере символов во время процесса автоматической сборки, а проект-потребитель настроен на использование этого сервера символов (параметры Visual Studio), проекты-потребители смогут выполнять ваш код так же, как если бы они pdb локально. (пользователи, не использующие tfs, могут использовать частные репозитории symbolsource.org и публиковать пакеты символов nuget). Эта установка работает для меня. - person Xavier Decoster; 07.10.2011
comment
потребителям потребуются разрешения на чтение источников для внутренних dll, через которые они хотят пройти. Безопасность TFS Source Control применяется автоматически при использовании встроенного сервера символов. Подводя итог: если у вас нет доступа для чтения к исходникам, вы не сможете пройти через них, что, я думаю, имеет смысл ;-) - person Xavier Decoster; 07.10.2011
comment
Итак, чтобы использовать Nugget в TFS, мне нужно использовать старую систему сборки, создать общий ресурс, куда я должен поместить все пакеты, или, что еще хуже, предоставить моему серверу сборки доступ к Интернету? - person Juan Zamudio; 29.02.2012
comment
Что не так с доступом к Интернету у ваших агентов сборки? Если вы действительно этого не хотите, проверьте пакеты в системе контроля версий (и получите их из Интернета самостоятельно). Не блокирует использование NuGet в TFS. - person Xavier Decoster; 04.03.2012
comment
@Xavier Decoster: Какая польза от наличия сервера сборки с доступом в Интернет? Кроме того, наши ИТ-специалисты не позволяют ни одному серверу иметь доступ к Интернету, и нет, чтобы ответить на ваш вопрос, это не блокирует меня, но это очень раздражает. - person Juan Zamudio; 12.06.2012
comment
@JuanZamudio Я чувствую вашу боль, был там, сделал это :) Я предпочитаю не размещать внутренний репозиторий NuGet и не использовать сервер сборки (из-за рабочей нагрузки, и у них обычно нет доступа в Интернет). Наличие сетевого ресурса в качестве центрального репозитория pkg, вероятно, является вашим выходом. Однако для этого требуется, чтобы кто-то (или что-то) поставил на них пакеты. Отразите нужные пакеты с nuget.org. Или у вас есть служба в вашей сети (размещенная на машине с доступом в Интернет), которая ретранслирует все вызовы на nuget.org (чтобы сервер сборки не общался с Интернетом напрямую) :) - person Xavier Decoster; 13.06.2012

arrow_upward
1
arrow_downward

Небольшое обновление принятого ответа и вопроса:

При использовании TFS в качестве сборочной машины без установленной на ней Visual Studio вы можете сделать следующее, чтобы сборочная машина автоматически использовала ваши настраиваемые источники пакетов (более 1 в одном решении) без какой-либо дополнительной настройки источников пакетов в вашем решении.

  1. Создайте конфигурацию компьютера по умолчанию, поместив NuGet.Config в корень ( C:\NuGet.Config ), используя образец из: http://docs.nuget.org/docs/reference/nuget-config-файл

  2. Закомментируйте строку с помощью: <add key="repositorypath" value="$\External\Packages" />

    В противном случае ваши пакеты будут развернуты в C:\$\External\packages\'. Когда закомментирован, конфигурация становится цепочкой, и будет использоваться правильный каталог.

  3. Настройте необходимые источники пакетов.

Дополнительные сведения о других параметрах (например, указанных пользователем) см. по адресу: http://docs.nuget.org/docs/reference/nuget-config-file (внизу страницы).

person Remco    schedule 15.08.2013