2015-04-01 3 views
1

При использовании автоматического восстановления пакета NuGet, добавленного в версии 2.7, NuGet автоматически загружает любые недостающие пакеты в папку \ pack, расположенную на уровне решения. Когда решение включает библиотеки (т.е. поддерева git или подмодули git), это вызывает проблемы, поскольку проекты библиотеки ожидают, что пакеты будут загружены в папку пакетов, расположенную в их соответствующей папке решения (которая обычно вложена в качестве подпапки внутри папки решения основного кода) и не знаю, как искать пакеты в папке решения основного кода. Например:Восстановление автоматического пакета NuGet создает проблемы для библиотек

primary_code_folder\ 
->primary_code.sln 
->packages\ 
    [various packages downloaded by NuGet] 
->primary_code_project\ 
->library_solution_folder\ 
--->library_code.sln 
--->packages\ 
     [where the library project expects packages to reside] 
--->library_code_project\ 

Потенциальных решения это:

  1. вручную открыть каждый проект библиотек .sln файл и компилирует проект, чтобы обеспечить самые последние пакеты будут восстановлены в каждой библиотеку папки пакета. Это нежелательно, так как каждый разработчик должен помнить об этом каждый раз, когда кто-то обновляет/устанавливает новый пакет.
  2. Как-то настроить каждую библиотеку так же, как и в папке пакетов в коде основного решения. Это похоже на крайне нежелательное исправление, потому что оно изменяет код библиотеки, чтобы быть уникальным для данного проекта, в котором он используется.
  3. Настройте решение основного кода для запуска nuget.exe restore library_code.sln в команде командной строки события pre-build. Однако nuget.exe не является естественным решением и не (по умолчанию) находится в переменной пути. Таким образом, похоже, что копирование nuget.exe в проект может привести к более поздней несовместимости, поскольку обновления не будут втянуты. Возможно, есть обходное решение для этого?
  4. Как-то настроить NuGet для хранения пакетов на уровне проекта вместо уровня решения?

Может ли кто-нибудь поделиться, как они подошли к этой проблеме? Аналогичный вопрос был задан здесь (NuGet Automatic Package Restore when using git submodules) для другой ситуации, и ответ не удовлетворяет потребностям, которые я описываю в этом посте.

+0

у меня была аналогичная проблема несколько месяцев назад и в итоге была поставлена ​​задача msbuild, аналогичная вашему решению №3, поскольку я не мог найти ничего лучшего. Проблема в том, что восстановление пакета - это функция Visual Studio, т. Е. Она не выполняется, если вы пытаетесь собрать материал не из исходного решения или с помощью командной строки msbuild. – Christoph

+0

Спасибо. Мне было интересно, возможно, восстановление пакета было частью Visual Studio. Одна из задач этого рабочего процесса заключается в том, что мы добавили проект библиотеки с использованием поддерева git и активно его редактируем. Поэтому, если мы внесем изменения в библиотеку, которая разбивает сборку, ошибка не будет отображаться должным образом в среде IDE, потому что задача msbuild завершится неудачно, прежде чем Visual Studio попытается скомпилировать основное решение. – elsevers

+0

То, что я еще не понял, - это то, каков ваш текущий и нужный рабочий процесс: строите ли вы библиотеку и основной код отдельно или хотите создать одноэтапную сборку всего. Если да, то это нужно выполнить в VS? И вы контролируете все проекты, то есть было бы приемлемо изменить решение библиотеки? – Christoph

ответ

1

Это можно сделать, разместив несколько файлов nuget.config в каждой папке, где существует sln.

В nuget.config вам необходимо добавить следующие

<config> 
<add key="repositoryPath" value="C:\Temp" /> 
</config> 

или

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

посмотрите здесь для получения более подробной информации https://docs.nuget.org/consume/nuget-config-settings

Смежные вопросы