Настройка общей папки пакетов nuget для всех решений, когда некоторые проекты включены в несколько решений

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

Я видел, что есть способы указать общее расположение пакета (возможно, на корневом уровне проекта, мы используем систему контроля версий TFS) с выпуском 2.1 NuGet, см. Примечания к выпуску . Я использую NuGet v2.7

Но я попытался добавить файлы nuget.config, но никакого эффекта от этого не увидел. Пакеты по-прежнему хранятся в папке решения. Я что-то пропустил? Кажется, есть разные структуры узла xml для добавления в файл nuget.config, в зависимости от того, кто отвечает на этот вопрос: Шварци предлагает в другом потоке Stackoverflow :

<settings>
  <repositoryPath>..\..\[relative or absolute path]</repositoryPath>
</settings>

В примечаниях к выпуску NuGet 2.1 (см. Ссылку выше) предлагается этот формат:

<configuration>
  <config>
    <add key="repositoryPath" value="..\..\[relative or absolute path]" />
  </config>
</configuration>

Я не знаю, какой из них, или любой, или оба сработают в итоге. Я пробовал оба на уровне решения. Можно ли разместить файл nuget.config на корневом уровне проекта TFS или он должен находиться в каталоге решения? Кажется, что NuGet считывает и применяет настройки из этих файлов в определенном порядке, поэтому имеет смысл добавлять их на нескольких уровнях, где файл nuget.config на уровне решения переопределяет один на корневом уровне проекта TFS. Можно это прояснить?

Нужно ли мне удалить все установленные пакеты, прежде чем эти ссылки будут работать? Мне бы очень хотелось, чтобы кто-нибудь мог предоставить пошаговую инструкцию по переходу от использования nuget для конкретного решения в общую папку пакетов, где проекты, принадлежащие к нескольким решениям, могут найти свои необходимые пакеты nuget.

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

• Кодовая база
  • Проект А
  • Проект Б
  • Проект C
  • Решения
    • Решение 1
    • Решение 2
    • Решение 3
    • Пакеты (общий для всех решений)

Обновленный ответ от NuGet 3.5.0.1484 с обновлением 3 для Visual Studio 2015

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

• Все, что необходимо внести в контроль исходного кода, видно и отслеживается в решении.
• При установке новых пакетов или обновлении пакетов с помощью диспетчера пакетов в Visual Studio будет использоваться правильный путь к репозиторию.
• После первоначальной настройки взлом файлов .csproj не будет
• Никаких модификаций рабочей станции разработчика (код готов к выпуску)

Есть некоторые потенциальные недостатки, о которых следует знать (я их еще не испытал, YMMV). См . Ответ и комментарии Бенола ниже.

Добавить NuGet.Config

Вам нужно создать файл NuGet.Config в корне папки \ Solutions \. Убедитесь, что это созданный вами файл в кодировке UTF-8. Если вы не знаете, как это сделать, используйте меню Visual Studio File-> New-> File, а затем выберите шаблон XML-файла. Добавьте в NuGet.Config следующее:

<?xml version="1.0" encoding="utf-8"?>
<configuration>  
  <config>
    <add key="repositoryPath" value="$\..\Packages" />
  </config>
</configuration>

Для параметра repositoryPath вы можете указать абсолютный или относительный путь (рекомендуется) с помощью токена $. Токен $ основан на том, где находится NuGet.Config (токен $ на самом деле относится к одному уровню ниже расположения NuGet.Config). Итак, если у меня есть \ Solutions \ NuGet.Config, и я хочу \ Solutions \ Packages, мне нужно будет указать $ \ .. \ Packages в качестве значения.

Затем вы захотите добавить к своему решению папку решения, которая называется что-то вроде «NuGet» (щелкните правой кнопкой мыши свое решение, «Добавить» -> «Новая папка решения»). Папки решения - это виртуальные папки, которые существуют только в решении Visual Studio и не создают фактическую папку на диске (и вы можете ссылаться на файлы из любого места). Щелкните правой кнопкой мыши папку решения «NuGet», затем «Добавить»> «Существующий элемент» и выберите \ Solutions \ NuGet.Config.

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

Помещая файл NuGet.Config в \ Solutions \ над любыми файлами .sln, мы пользуемся тем фактом, что NuGet будет рекурсивно перемещаться по структуре папок вверх от «текущего рабочего каталога» в поисках файла NuGet.Config для использования. «Текущий рабочий каталог» означает здесь несколько разных вещей: один - это путь выполнения NuGet.exe, а другой - расположение файла .sln.

Переключение папки пакетов

Во-первых, я настоятельно рекомендую вам просмотреть все папки вашего решения и удалить все существующие папки \ Packages \ (сначала вам нужно закрыть Visual Studio). Это упрощает просмотр того, куда NuGet помещает вашу недавно настроенную папку \ Packages \, и гарантирует, что любые ссылки на неправильную папку \ Packages \ не будут работать и их можно будет исправить.

Откройте свое решение в Visual Studio и запустите Rebuild All. Игнорируйте все ошибки сборки, которые вы получите, это ожидается на данном этапе. Однако это должно запустить функцию восстановления пакета NuGet в начале процесса сборки. Убедитесь, что ваша папка \ Solutions \ Packages \ создана в нужном месте. Если нет, проверьте свою конфигурацию.

Теперь для каждого проекта в вашем решении вам нужно:

1. Щелкните проект правой кнопкой мыши и выберите «Выгрузить проект».
2. Щелкните проект правой кнопкой мыши и выберите Edit your-xxx.csproj.
3. Найдите все ссылки на \ packages \ и обновите их в новом месте.
   • Большинство из них будут ссылками на <HintPath>, но не все. Например, WebGrease и Microsoft.Bcl.Build будут иметь отдельные параметры пути, которые необходимо обновить.
4. Сохраните .csproj, а затем щелкните проект правой кнопкой мыши и выберите «Обновить проект».

Как только все ваши файлы .csproj будут обновлены, запустите еще одну Rebuild All, и у вас больше не должно быть ошибок сборки, связанных с отсутствующими ссылками. На этом все готово, и теперь у NuGet настроено использование общей папки пакетов.

Начиная с NuGet 2.7.1 (2.7.40906.75) с VStudio 2012

Прежде всего, следует иметь в виду, что nuget.config не контролирует все параметры пути в системе пакетов nuget. Это было особенно сложно понять. В частности, проблема заключается в том, что msbuild и Visual Studio (вызывающие msbuild) не используют путь в nuget.config, а переопределяют его в файле nuget.targets.

Подготовка окружающей среды

Во-первых, я бы просмотрел папку вашего решения и удалил все существующие папки \ packages \. Это поможет обеспечить видимую установку всех пакетов в правильную папку и поможет обнаружить любые ссылки на неправильные пути во всех ваших решениях. Затем я хотел бы убедиться, что у вас установлено последнее расширение Nuget Visual Studio. Я также хотел бы убедиться, что у вас установлена ​​последняя версия nuget.exe в каждом решении. Откройте командную строку, войдите в каждую папку $ (SolutionDir) \ .nuget \ и выполните следующую команду:

nuget update -self

Установка пути к общей папке пакета для NuGet

Откройте каждый $ (SolutionDir) \ .nuget \ NuGet.Config и добавьте следующее в раздел <configuration>:

<config>
    <add key="repositorypath" value="$\..\..\..\Packages" />
</config>

Примечание. Вы можете использовать абсолютный или относительный путь. Имейте в виду, что если вы используете относительный путь с $, он относится к одному уровню ниже местоположения NuGet.Config (считаю, что это ошибка).

Установка пути к общей папке пакета для MSBuild и Visual Studio

Откройте каждый $ (SolutionDir) \ .nuget \ NuGet.targets и измените следующий раздел (обратите внимание, что для не-Windows есть еще один раздел под ним):

<PropertyGroup Condition=" '$(OS)' == 'Windows_NT'">
    <!-- Windows specific commands -->
    <NuGetToolsPath>$([System.IO.Path]::Combine($(SolutionDir), ".nuget"))</NuGetToolsPath>
    <PackagesConfig>$([System.IO.Path]::Combine($(ProjectDir), "packages.config"))</PackagesConfig>
    <PackagesDir>$([System.IO.Path]::Combine($(SolutionDir), "packages"))</PackagesDir>
</PropertyGroup>

Обновить PackagesDir to be

<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>

Примечание: GetFullPath преобразует наш относительный путь в абсолютный путь.

Восстановление всех пакетов nuget в общую папку

Откройте командную строку и перейдите к каждому $ (SolutionDir) \ .nuget и выполните следующую команду:

nuget restore ..\YourSolution.sln

На этом этапе у вас должна быть одна папка \ packages \ в вашем общем расположении и ни одной папки ни в одной из папок вашего решения. Если нет, то проверьте свои пути.

Исправление ссылок на проекты

Откройте каждый файл .csproj в текстовом редакторе, найдите все ссылки на \ packages и обновите их до правильного пути. Большинство из них будут ссылками на <HintPath>, но не все. Например, WebGrease и Microsoft.Bcl.Build будут иметь отдельные параметры пути, которые необходимо обновить.

Создайте свое решение

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

Возникла ошибка сборки из-за отсутствующих пакетов?

Если вы уже убедились, что пути в ваших файлах .csproj верны, вы можете попробовать два варианта. Если это результат обновления кода из элемента управления исходным кодом, вы можете попробовать получить чистую копию, а затем создать ее. Это сработало для одного из наших разработчиков, и я думаю, что в файле .suo был артефакт или что-то подобное. Другой вариант - вручную принудительно восстановить пакет с помощью командной строки в папке .nuget рассматриваемого решения:

nuget restore ..\YourSolution.sln

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

<HintPath>$(SolutionDir)\packages\EntityFramework.6.1.0\lib\net40\EntityFramework.dll</HintPath>

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

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

Мой опыт работы с последней версией NuGet (2.7) и VS2012:

• Удалите папку .nuget (на диске и в растворе)
• Поместите файл NuGet.Config в общую родительскую папку всех решений.
• Удалите все существующие папки пакетов
• Просмотрите все файлы csproj и измените HintPaths, чтобы они указывали на новое местоположение
• Прибыль

В моем случае я хотел разместить все пакеты .packages, поэтому мой NuGet.Config выглядел так, как показано ниже.

 <?xml version="1.0" encoding="utf-8"?>
 <configuration>
   <config>
     <add key="repositorypath" value=".packages" />
   </config>
 </configuration>

Обратите внимание, что может произойти несколько «странных» вещей, но я думаю, что они терпимы:

• Если вы «Обновите» пакет из одного решения, он сразу же удалит старую версию из папки ваших пакетов (он не может знать, есть ли у вас другое решение, указывающее на него). Это меня не сильно беспокоит, так как другое решение просто восстановит при необходимости.
• Если вы попытаетесь добавить пакет из решения, щелкнув правой кнопкой мыши, если пакет уже присутствует в другом решении, он увидит его и покажет вам «зеленую галочку» вместо кнопки «установить». Я обычно устанавливаю из проекта, щелкнув правой кнопкой мыши, поэтому меня это совершенно не беспокоит.

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

У меня NuGet версии 2.8.50926 с VS 2013. Вам не нужно использовать несколько файлов nuget.config или использовать сложные структуры каталогов. Просто измените файл по умолчанию, расположенный здесь:

%APPDATA%\Roaming\NuGet\NuGet.Config

Вот содержимое моего файла:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <config>
    <add key="repositoryPath" value="C:\Projects\nugetpackages" />
  </config>
  <activePackageSource>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </activePackageSource>
</configuration>

Таким образом, все пакеты попадают в папку «C: \ Projects \ nugetpackages», независимо от того, где находится решение.

Во всех ваших решениях просто удалите существующие папки «пакетов». Затем создайте свое решение, и NuGet автоматически восстановит отсутствующие пакеты в новом централизованном каталоге, который вы указали.

Уже нет необходимости изменять nuget.targets. Это было исправлено в nuget 2.8 ( http://nuget.codeplex.com/workitem/2921 ). Вам нужно только указать путь к репозиторию.

Из Visual Studio 2013 с обновлением 4 и версии диспетчера пакетов слепков> 2.8.5 ...

Создайте файл nuget.config в корне репозитория.

содержимое файла:

<configuration>
  <config>
    <add key="repositoryPath" value="packages" />
  </config>
  <packageSources>
    <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
  </packageSources>
</configuration>

Это приведет к тому, что все пакеты попадут в папку пакетов на уровне вашего файла nuget.config.

Теперь вы можете перейти к каждой консоли .sln nuget с помощью команды update-package -reinstall.

Если у вас есть несколько репозиториев на одном уровне и для совместного использования одной и той же папки пакета, попробуйте использовать способ перехода на одну папку вверх.

 <add key="repositoryPath" value="..\packages" />

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

Я придумал пакет NuGet, который прозрачно преобразует все ссылки NuGet в проекте в формат, связанный с $ (SolutionDir). Это делается с помощью XSLT-преобразования во время сборки, поэтому вам не нужно вручную взламывать файл проекта. Вы можете свободно обновлять свои пакеты, это ничего не сломает.

https://www.nuget.org/packages/NugetRelativeRefs

Или вы, если вы используете Visual Studio 2015 с обновлением 3, вы можете просто перенести ссылки на пакеты в project.jsonформу, как описано здесь: https://oren.codes/2016/02/08/project-json-all-the-things

Обновление моего опыта работы с nuget 2.8.3. Это было относительно просто. Все, что было сделано, было включено восстановление пакета из решения, щелкнув правой кнопкой мыши. Отредактировал NuGet.Config и добавил эти строки:

  <config>
    <add key="repositorypath" value="..\Core\Packages" />
  </config>

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

Вот пошаговая процедура включения восстановления пакета.

http://blogs.4ward.it/enable-nuget-package-restore-in-visual-studio-and-tfs-2012-rc-to-building-windows-8-metro-apps/

Просто установите жесткую ссылку / пакеты на желаемое общее местоположение. Тогда ваш проект не будет нарушен для других пользователей, у которых нет специального расположения пакетов.

Откройте командную строку от имени администратора и используйте

mklink /prefix link_path Target_file/folder_path

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

Использование ($ SolutionDir) - шаг в правильном направлении, но ручное кодирование файла csproj с помощью ($ SolutionDir) стало бы довольно утомительным в базе кода с сотнями пакетов, которые регулярно обновляются (каждый раз, когда происходит обновление, HintPath перезаписывается с помощью новый относительный путь). Что произойдет, если вам нужно запустить Update-Package -Reinstall.

Есть отличное решение под названием NugetReferenceHintPathRewrite . Он автоматизирует внедрение ($ SolutionDir) в HintPaths непосредственно перед сборкой (без фактического изменения файла csproj). Я полагаю, это можно легко включить в автоматизированные системы сборки.

Краткое описание для профессионалов VS 2013 с версией NuGet : 2.8.60318.667

Вот как вы направляете пакеты по пути относительно папки .nuget:

<configuration>
  <config>
    <add key="repositoryPath" value="../Dependencies" />
  </config>
</configuration>

Например, если ваше решение (файл .sln) находится в C: \ Projects \ MySolution, когда вы включаете восстановление пакетов NuGet, папка .nuget создается следующим образом: C: \ Projects \ MySolution.nuget, и пакеты будут загружены в такой каталог: C: \ Projects \ MySolution \ Dependencies

ПРИМЕЧАНИЕ. По какой-то (неизвестной) причине каждый раз, когда я обновляю "repositoryPath", мне приходится закрывать и снова открывать решение, чтобы изменения вступили в силу.

для тех, кто использует paket в качестве менеджера пакетов, есть опция автоматической символьной ссылки для вашего файла зависимостей:

storage: symlink

кстати: пакет использует nuget

ссылка: https://fsprojects.github.io/Paket/dependencies-file.html

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

Я просто использую NTFS-соединения, чтобы сделать все папки пакетов прямыми в одной папке над корнями репозитория. Работает отлично. Нет проблем с параллельным восстановлением пакетов из нескольких решений. Одним из преимуществ этого является то, что вам не нужно вообще ничего перенастраивать в исходном коде, например, сотни относительных путей подсказок в ваших файлах .csproj. Он «просто работает», позволяя файловой системе обрабатывать перенаправление и моделирование отдельной папки пакетов.

Просто остерегайтесь проблем с git. Хотя «git status» через командную строку не показывает неустановленных изменений, я заметил, что GitKraken видит пересечение «пакетов» как неустановленный файл . Он даже показывает ошибки типа «файл - это каталог», когда вы щелкаете по нему. GitKraken также попытается спрятать этот «файл», если вы перебазируете его, уничтожив соединение и восстановив его как фактический файл, содержащий текст с исходным путем к файлу. Очень странное поведение. Возможно, вы сможете обойти это, добавив файл пакетов в ваш .gitignore.

Это инструкции для NuGet 2.1: http://docs.nuget.org/docs/release-notes/nuget-2.1

Нет необходимости редактировать файлы уровня решения.

Работает с Visual Studio 2013 и тремя проектами совместного использования решений.

Не забудьте обновить NuGet на уровне решения (каждый файл nuget.exe в папках .nuget).