У мене схожа ситуація із зовнішніми та внутрішніми джерелами пакетних пакетів з проектами, на які посилається більше ніж одне рішення. Сьогодні я працював з однією з наших баз коду і, здається, працює з робочими станціями розробника та нашим сервером збірки. Наведений нижче процес має на увазі цей сценарій (хоча це не повинно бути важко адаптуватися, щоб мати загальну папку пакунків в іншому місці).
- Кодова база
- Проект А
- Проект B
- Проект С
- Рішення
- Рішення 1
- Рішення 2
- Рішення 3
- Пакети (це загальне для всіх рішень)
Оновлений відповідь станом на NuGet 3.5.0.1484 з Visual Studio 2015 Update 3
Зараз цей процес трохи простіший, ніж коли я спочатку вирішував це і думав, що настав час його оновити. Загалом, процес той самий лише з меншими кроками. Результатом є процес, який вирішує або забезпечує наступне:
- Все, що потрібно зарахувати до управління вихідним кодом, видно і відстежується в рішенні
- Встановлення нових пакетів або оновлення пакетів за допомогою диспетчера пакетів у Visual Studio буде використовувати правильний шлях до репозиторію
- Після початкової конфігурації не відбувається злому файлів .csproj
- Жодних модифікацій робочої станції розробника (код готовий до виїзду)
Слід пам’ятати про деякі потенційні недоліки (я ще не відчував їх, YMMV). Дивіться відповідь та коментарі Бенола нижче.
Додати NuGet.Config
Вам потрібно створити файл NuGet.Config у корені папки \ Рішення \. Переконайтеся, що це створений вами UTF-8 файл, якщо ви не впевнені, як це зробити, скористайтеся меню Файл-> Нове-> Файл Visual Studio і виберіть шаблон файлу XML. Додайте до NuGet.Config наступне:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositoryPath" value="$\..\Packages" />
</config>
</configuration>
Для налаштування Path repositoryPath ви можете вказати абсолютний шлях або відносний шлях (рекомендований), використовуючи маркер $. $ Токен заснований на тому, де знаходиться NuGet.Config (маркер $ насправді відносно одного рівня нижче місця розташування NuGet.Config). Отже, якщо у мене є \ Solutions \ NuGet.Config, і я хочу \ Solutions \ Packages, мені потрібно вказати $ \ .. \ Packages як значення.
Далі ви хочете додати до вас папку рішення, яка називається на зразок "NuGet" (клацніть правою кнопкою миші на своєму рішенні, Add-> New Solution Folder). Папки рішення - це віртуальні папки, які існують лише в рішенні Visual Studio і не створюють фактичну папку на диску (і ви можете посилатися на файли з будь-якого місця). Клацніть правою кнопкою миші на папці рішення «NuGet», а потім Додати-> існуючий елемент та виберіть \ Рішення \ NuGet.Config.
Причина, з якої ми це робимо, полягає в тому, щоб це було видно у рішенні та повинно допомогти переконатися, що воно належним чином контролюється вашим вихідним кодом. Ви можете зробити цей крок для кожного рішення вашої кодової бази, яка бере участь у спільних проектах.
Розміщуючи файл NuGet.Config у \ Solutions \ над будь-якими файлами .sln, ми використовуємо той факт, що NuGet рекурсивно перемістить структуру папки вгору від "поточної робочої директорії", шукаючи файл NuGet.Config, який слід використовувати. "Поточний робочий каталог" означає кілька різних речей тут, один - це шлях виконання NuGet.exe, а другий - розташування файлу .sln.
Перемикання папки ваших пакетів
По-перше, настійно рекомендую пройти кожну папку рішення та видалити будь-які \ Пакети \ папки, які існують (спочатку потрібно закрити Visual Studio). Це полегшує зрозуміти, куди NuGet розміщує вашу нещодавно налаштовану папку \ Packages \, і гарантує, що будь-які посилання на неправильну \ Packages \ папку не зможуть і потім можуть бути виправлені.
Відкрийте своє рішення у Visual Studio і розпочніть Rebuild All. Ігноруйте всі отримані вами помилки побудови, це очікується в цей момент. Це повинно розпочати функцію відновлення пакету NuGet на початку процесу збирання. Переконайтесь, що папка \ Рішення \ Пакети \ створена у потрібному місці. Якщо цього немає, перегляньте конфігурацію.
Тепер для кожного проекту у вашому рішенні потрібно:
- Клацніть правою кнопкою миші на проект та виберіть Unload Project
- Клацніть правою кнопкою миші на проект і виберіть Редагувати свій xxx.csproj
- Знайдіть будь-які посилання на \ пакети \ та оновіть їх до нового місця розташування.
- Більшість із них будуть <HintPath> посиланнями, але не всі вони. Наприклад, WebGrease та Microsoft.Bcl.Build матимуть окремі налаштування шляху, які потрібно буде оновити.
- Збережіть .csproj, а потім клацніть правою кнопкою миші на проект і виберіть Перезавантажити проект
Після того, як усі ваші .csproj файли будуть оновлені, розпочніть іншу Rebuild All, і у вас більше не повинно виникати помилок щодо відсутніх посилань. На даний момент ви закінчили, і тепер NuGet налаштований на використання спільної папки Packages.
Станом на NuGet 2.7.1 (2.7.40906.75) з VStudio 2012
Перш за все, що потрібно пам’ятати, це те, що nuget.config не контролює всі налаштування шляху в системі пакетів nuget. Це було особливо незрозуміло. Зокрема, проблема полягає в тому, що msbuild та Visual Studio (викликає msbuild) не використовують шлях у nuget.config, а навпаки, переосмислюють його у файлі nuget.targets.
Підготовка навколишнього середовища
По-перше, я перегляну папку вашого рішення і видалю всі \ пакети \ папки, які існують. Це допоможе забезпечити видимість встановлення всіх пакунків у правильну папку та допоможе виявити будь-які погані посилання на шляху у ваших рішеннях. Далі я б переконався, що у вас встановлено останнє розширене розширення 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>
Оновіть пакетиDir бути
<PackagesDir>$([System.IO.Path]::GetFullPath("$(SolutionDir)\..\Packages"))</PackagesDir>
Примітка: GetFullPath вирішить наш відносний шлях в абсолютний шлях.
Відновлення всіх пакунків нута в загальну папку
Відкрийте командний рядок і перейдіть до кожного $ (SolutionDir) \ .uget і виконайте таку команду:
nuget restore ..\YourSolution.sln
У цей момент у вас має бути одна \ папка \ папка у вашому загальному місці розташування, і жодна в жодній із ваших папок рішення. Якщо ні, то перевіряйте свої шляхи.
Виправлення посилань на проект
Відкрийте кожен .csproj-файл у текстовому редакторі та знайдіть посилання на \ пакети та оновіть їх до правильного шляху. Більшість із них будуть <HintPath> посиланнями, але не всі вони. Наприклад, WebGrease та Microsoft.Bcl.Build матимуть окремі налаштування шляху, які потрібно буде оновити.
Побудуйте своє рішення
Відкрийте своє рішення у Visual Studio і розпочніть збірку. Якщо він скаржиться на відсутні пакети, які потрібно відновити, не вважайте, що пакет відсутній і його потрібно відновити (помилка може ввести в оману). Це може бути поганим шляхом до одного з ваших файлів .csproj. Перш ніж відновити пакет, перевірте це.
У вас є помилка збірки щодо відсутніх пакетів?
Якщо ви вже переконалися, що шляхи у ваших .csproj файлах правильні, ви можете спробувати два варіанти. Якщо це результат оновлення коду від контролю вихідного коду, ви можете спробувати перевірити чисту копію, а потім створити її. Це працювало для одного з наших розробників, і я думаю, що у файлі .suo був артефакт чи щось подібне. Інший варіант - вручну змусити відновити пакет, використовуючи командний рядок у папці .nuget відповідного рішення:
nuget restore ..\YourSolution.sln
$перед відносним шляхом. Також відповідь на ваше запитання про файли NuGet.Config є тут . Спочатку він виглядає у .nuget, потім у всіх батьківських каталогах, потім у «глобальному» файлі у вашій AppData: потім застосовує їх у порядку REVERSE (все, що це означає).