Вопрос по nuget, msbuild, package-managers, tfs – NuGet Package Restore не восстанавливает пакеты при сборке

11

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

Решение имеет несколько проектов, и у каждого есть как минимум один пакет NuGet. Я пытаюсь заставить Пакет Восстановить работать снова. Это работало в Vault (но не так, как предполагалось). У меня был какой-то крайний срок, и поначалу он не работал, поэтому я добавил событие Pre-Build для запуска nuget.exe для файла packages.config для каждого проекта.

Сервис сборки TFS жалуется на это, поэтому я пытаюсь заставить его работать "право".

Я установил опцию в меню Visual Studio Tools.Я установил NuGetEnablePackageRestore и запустил исправление.Я проверил, что каталог пакетов является системой контроля версий, но он пуст.Я проверил, что каждый из файлов проекта включает следующее:
true

Сборка с подробным уровнем диагностики показывает, что каждый проект оценивает эти свойства, но RestoreCommand в nuget.targets никогда не выполняется.

Какие-нибудь мысли?

Я попытался реализовать решения по этим ссылкам:

nuget - восстановление пакета не работаетВосстановление пакета NuGet не работает - Я опубликовал вопрос / комментарий с просьбой дать разъяснения ...http://nuget.codeplex.com/workitem/1879редактировать

Кроме того, я обнаружил, что свойство RestoreCommand оценивается во время сборки. Диагностическая детализация показывает:

RestoreCommand = (set EnableNuGetPackageRestore=true) && "C:\Source\Kiersted Direct And Related\Direct\Kiersted\.nuget\nuget.exe" install "packages.config" -source "@(PackageSource)" -o "C:\Source\Kiersted Direct And Related\Direct\Kiersted\packages"

Ваш Ответ

2   ответа
10

MSBuild не запускает задачи BuildDependsOn из импортированного проекта

Проблема (после просмотра результатов построения многословной диагностики) заключалась в том, что параметр BuildDependsOn не был установлен. Каждый из файлов моего проекта имел оператор импорта

<import project="$(SolutionDir)\.nuget\nuget.targets">
</import>

но это утверждение было в начале дерева XML. Очевидно, что импорт для Microsoft.CSharp.targets может помешать этому импорту и, следовательно, BuildDependsOn.

Моим решением было переместить импорт nuget.targets ниже уровня импорта Microsoft.CSharp.targets. Теперь все строит красиво.

Я думаю, что это проблема hintpath, как указано здесь:stackoverflow.com/questions/21620083/... но я все еще должен исправить это полностью. Dan Csharpster
Да, это может быть неприятно. Эти предупреждения появляются перед попыткой восстановления пакетов nuGet? Вы когда-нибудь добирались до линии RestoreCommand? CodeWarrior
Спасибо за информацию. Тем не менее, мой оператор импорта уже после импорта Microsoft.CSharp, и я 'Я получу ту же ошибку. Я'продолжу копать и посмотрим, что здесь происходит. Dan Csharpster
я вижу это как предупреждение: C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (1605): не удалось разрешить эту ссылку. Не удалось найти сборку "MongoDB.Bson».Проверьте, существует ли сборка на диске. Если эта ссылка требуется вашим кодом, вы можете получить ошибки компиляции. C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Microsoft.Common.targets (1605): не удалось разрешить эту ссылку. Не удалось найти сборку "MongoDB.Driver», Убедитесь, что сборка существует на диске. Если эта ссылка требуется вашим кодом, вы можете получить ошибки компиляции Dan Csharpster
В выходных данных Build попробуйте указать Diagnostic. Он выводит огромное количество журналов, но проблема где-то там. Вот так я и понял. CodeWarrior
0

io решила не добавлять пакеты package.config автоматически в Source Control. Следовательно, файл не сделал этоs путь к серверу сборки для рассмотрения во время восстановления Nuget.

Похожие вопросы