NuGet Respository для TFS Build - PullRequest
0 голосов
/ 08 мая 2018

Я не могу найти четкий ответ во всех моих поисках. У нас TFS 2015 и мы хотим использовать собственный репозиторий NuGet для хранения наших внутренних пакетов.

В настоящее время они находятся на физическом диске на том же сервере, что и установка TFS. Однако он постоянно не может найти ни одного из пакетов.

Мое замешательство возникает здесь. Чтобы использовать этот каталог в качестве репозитория Nuget, нам нужно установить дополнительное программное обеспечение или сгенерировать index.json? Наличие пакетов в папке не достаточно? Я видел много статей, рассказывающих о плагине управления пакетами (стоимость которого превышает 5 человек) или об обновлении до TFS 2017.

Правильно ли я понимаю, что недостаточно просто хранить пакеты в расположении, к которому у сервера есть доступ, и указывать на него?

Спасибо!

Ответы [ 2 ]

0 голосов
/ 15 мая 2018

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

Чтобы использовать каталог в качестве репозитория Nuget, вам не нужно ничего устанавливать, но вы должны знать пару вещей. У вас есть 2 способа ссылаться на ваши пакеты: вы можете использовать ссылки на пакеты, используя узел PackageReference, и он управляет зависимостями NuGet непосредственно в файлах проекта, а во-вторых, в отличие от него, узел Packages.config, который сохраняет конфигурацию в файле .config. .

enter image description here

Большое дело в том, что PackageReference используется для проектов .NET Core, так что за проекты какого типа вы пытаетесь построить?

.NET-проекты с полным каркасом поддерживают PackageReference, но в настоящее время по умолчанию используется package.config

Мое предложение: -Если вы имеете дело с проектом .netcore, используйте PackageReference, откройте ваши решения и посмотрите, все ли зависимости указывают на

% SystemDrive% \ Users \ .nuget

Для правильной компиляции в TFS должен быть один и тот же путь, из соображений оптимизации не следует перемещать эту папку в другую, поэтому, если вы отвечаете за TFS, следите за пространством диска C, поскольку он может увеличиваться экспоненциально.

- если вы не имеете дело с .NetFramework, а не с Core, то вам следует создать локальное репо, как сказал @Andy Li-MSFT. Я предлагаю вам прочитать этот ответ, который я опубликовал здесь некоторое время назад, шаг за шагом: https://stackoverflow.com/a/43791395/819153

0 голосов
/ 09 мая 2018

UPDATE:

Согласно комментариям BehemothDan ниже, эта проблема была решена установкой Nuget.Server в качестве приложения на сервере в IIS. Просто предоставьте процессу сборки TFS URL-адрес, а не путь к каталогу, все работает отлично. (Направьте Nuget.Server на каталог)


Так же, как Дэниел сказал: «NuGet будет использовать этот источник пакета. Ничего общего с TFS. Все, что делает система сборки, это запускает что-то из командной строки». *

Итак, вам просто нужно установить источник:

  1. Создать Локальный канал ( репозиторий nuget , это может быть папка общего доступа к которым может обращаться TFS.)
  2. Загрузите / скопируйте необходимые пакеты в папку репо.
  3. Установить источник пакета в nuget.config или напрямую добавить источник в Visual Studio.

Таким образом, nuget определит источник и автоматически восстановит пакеты при сборке в TFS.

Вы можете сослаться на эту статью, чтобы понять, что:

Создание локального репозитория NuGet для автономной разработки


Кроме того, TFS представила функцию Управление пакетами в TFS 2017 и более поздних версиях.

Таким образом, вы можете напрямую управлять пакетами в TFS при обновлении до TFS 2017 или более поздней версии.

Подробнее см. Начало работы с управлением пакетами NuGet в VSTS и TFS .

Эту статью также можно сослаться на Публикация на частном сервере NuGet из TFS2017 Build

...