2013-12-03 1 views
1

Я пытаюсь настроить автоматическую проверку моего MVC4 приложения с помощью NDbUnit в Дженкинс. На моей локальной машине у меня есть ссылки на NDbUnit.core и NDbUnit.SqlClient, которые я добавил в обозревателе решений, щелкнув папку Ссылки, а затем «Добавить ссылку», а затем добавить их с диска. Они работают как шарм.Как добавить правильную ссылку на зависимость, чтобы она работала на всех компьютерах (включая сервер сборки)?

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

c:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3245: 
Could not resolve this reference. Could not locate the assembly "NDbUnit.Core". Check to make 
sure the assembly exists on disk. If this reference is required by your code, you may get 
compilation errors. [C:\Program Files (x86)\Jenkins\jobs\Project\workspace\Project\Project.csproj] 
     For SearchPath "{HintPathFromItem}". 
     Considered "..\packages\NDbUnit_1.6.7.0\NDbUnit.Core.dll", but it didn't exist. 

Когда я сделать свежее извлечение и попытаться построить решение на моей машине, я получаю то же сообщение, что ссылка не может быть решена. Эти два файла, однако, находятся в папке «Ссылки», они просто не работают (в отличие от других, рядом с ними есть символ восклицательного знака). Только когда я ссылаюсь на них со своей машины, они работают снова.

Это безумие стоило мне много очков в игре непрерывной интеграции. Надеюсь, кто-то может объяснить мне, как я могу правильно ссылаться на .dll, чтобы они работали повсюду.

ответ

5

Обычно вам нужно сделать 2 вещи, чтобы убедиться, что узлы доступны:

  1. Проверить двоичные файлы в систему управления версиями. Некоторые системы управления исходными кодами могут сначала отступить, так как они являются двоичным форматом, но обычно вы можете заставить его. (Я знаю с TFS, если вы делаете tf add Foo.*, он пропустит DLL, поэтому вам нужно сделать явно tf add Foo.dll.)
  2. Убедитесь, что вы ссылаетесь на DLL с правильного относительного пути. Это указано как HintPath в файле проекта, например.

    <Reference Include="DllThatYouReference"> 
        <HintPath>../../relative/path/to/DllThatYouReference.dll</HintPath> 
    </Reference> 
    

Альтернативы делать это вручную, чтобы использовать менеджер пакетов, такой как Nuget. Когда вы устанавливаете пакет Nuget, он будет настраивать HintPath для этой ссылки в файле проекта. Вы также можете настроить его на install the necessary packages at build time, если они еще не доступны, что добавляет немного времени компиляции в обмен на то, что вам не нужно проверять файлы DLL.

Эти два файла, однако, находятся в папке «Ссылки», они просто не работают (в отличие от других, рядом с ними есть символ восклицательного знака).

Папка «Референции» на самом деле не является папкой, это список всех сборок, которые ссылаются на ваш проект. Эта информация найдена из файла проекта, поэтому они будут отображаться независимо от того, существуют ли файлы локально. Восклицательный знак указывает, что файлы отсутствуют (или не могут быть разрешены по какой-либо другой причине, но из вашего сообщения об ошибке они, вероятно, отсутствуют).

+0

Спасибо за пояснения. С NuGet файлы действительно были добавлены правильно. Сначала я не использовал его, так как по какой-то причине я не мог найти файлы. –

+0

Cheking в двоичных файлах для контроля источника, кажется, плохая идея и обходной путь в лучшем случае? –

+0

@ AndersLindén Если вы используете Git, я бы очень осторожно проверять в двоичные файлы, если они регулярно меняются, так как это будет раздуваться репозиторий с течением времени. В противном случае проверка бинарных файлов - это, вероятно, самый безопасный способ убедиться, что ваши зависимости доступны.Кто знает, какие менеджеры пакетов по-прежнему будут активно размещаться через 5 или 10 лет, когда ваш проект все еще работает и требует обслуживания. – Jimmy

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