VisualStudio.com (Visual Studio Team Services) сборки отказывают на зависимостях пакета nuget


Думал, я хотел бы попробовать и получить максимальную отдачу от моей триальный visualstudio.com . Я создал решение с несколькими проектами, передал его поставщику системы управления версиями Microsoft git, настроил определение сборки и попытался построить его на сервере project server. Однако он продолжает отказывать мне, говоря:

Тип или имя пространства имен "Moq" не удалось найти (вы отсутствует директива using или ссылка на сборку?)

Я знаю, что это означает, что сервер сборки не может найдите Moq.DLL-библиотека. Я установил его с помощью NuGet, но настроил свой .gitignore, чтобы сохранить папку packages вне системы управления версиями. Я также включил NuGet package restore для решения и нажал nuget.отлично, нугет.мишени и нугет.config (все 3 файла в списке .NuGet folder) вместе со всеми другими файлами проекта.

Теперь я уверен, что смог бы заставить сборку работать, если бы я также толкнул папку packages, но я хочу сохранить папку NuGet packages вне исходного кода контроль. Итак, я задаюсь вопросом, возможно ли это? Тот самый visualstudio.com документы говорят, что на серверах сборки установлена visual studio 2013, и поэтому я предполагаю, что NuGet package restore будет работать для загрузки отсутствующих dll-файлов, чтобы они могли быть разрешены MSBuild. Это правильно? Или использовать автоматизированные сборки CI на visualstudio.com, вам нужно, чтобы ваши пакеты находились под управлением исходного кода?

Согласно файлу журнала, NuGet package restore загрузил пакет. Что дает?

Проект "C:asrcMySln.sln " (1) строит "C:asrcTestsMySln.Проя.Unit-ТестовСайту Mysln.Проя.Unit-тестов.csproj" (3) на узле 1 (цели по умолчанию). Реставрационные пакеты:
"C:asrc.из NuGetNuGet для.exe " установка "C:asrcTestsMySln.Проя.Unit-тестовпакеты.config " - источник "" - Неинтерактивный-Requirereconsent-solutionDir "C:asrc" восстановление пакетов NuGet... Чтобы предотвратить загрузку пакетов NuGet во время постройте, откройте диалоговое окно Параметры Visual Studio, нажмите на пакет Узел диспетчера и снимите флажок "Разрешить NuGet загружать отсутствующие пакеты".
Все пакеты перечислены в пакетах.конфиг уже установлен. PrepareForBuild: создание каталога " objDebug". ResolveAssemblyReferences: первичная ссылка "Moq". C:Program Файлы (x86)MSBuild12.0binamd64Microsoft.Общий.CurrentVersion.цели(1635,5): предупреждение MSB3245: не удалось разрешить эту ссылку. Не удалось найти сборка "Moq". Проверьте, чтобы убедиться, что сборка существует на диске. Если эта ссылка необходима вашему коду, вы можете получить компиляцию ошибки. [C:asrcTestsMySln.Проя.Unit-ТестовСайту Mysln.Проя.Unit-тестов.csproj]

Эта строка также находится в файле журнала сборки, ниже приведенного выше:

Считается".. пакетыMoq.4.1.1311.0615 lib net40 Moq.dll", но его не существовало.

2 4

2 ответа:

У меня была такая же ошибка, но она происходила на нашем сервере сборки. Я добавил Moq через NuGet, проверил проект, и все было в порядке. Затем я переместил проект в новую папку в TFS, и сервер сборки просто не мог найти Moq. Это было отличное здание на местном уровне. В конечном итоге я решил проблему, убедившись, что все мои изменения были проверены в системе управления версиями, а затем удалил свой локальный каталог исходного кода. Я получил последнюю версию, и мой тестовый проект понял, что ему нужна новая копия Moq. Я обвиняю TFS / source safe или то, что когда-либо модуль интеграции Visual Studio не добавляет его в систему управления версиями в определенный момент времени.

Понял это сам. Оказывается, я добавил пакеты nuget перед перемещением тестового проекта в подпапку Tests. Решение все еще построено на моем LM, вероятно, потому, что зависимости уже были скопированы в bin / Debug. После переустановки пакетов nuget решение, построенное на vs.com.