Автоматизация создания пакета NuGet как часть процесса сборки
У меня есть автоматизированный процесс сборки, который я хотел бы расширить, чтобы я мог собирать библиотеки, распространяемые через NuGet. В настоящее время запуск nuget.exe для создания пакетов выполняется вручную.
Как лучше всего настроить VS 2010, чтобы мой файл пакета NuGet (*.nupkg) был конечным результатом сборки "Release"?
Имейте в виду, что у меня есть другие файлы (контент и инструменты) для некоторых пакетов. И в большинстве случаев у меня есть несколько проектов, объединенных в один пакет NuGet для поддержки.NET 4, Silveright и Phone 7.
(Я должен уточнить, что существующий "автоматизированный" процесс - это простой обработчик пакетных файлов, который строит решение с помощью командной строки.)
ОБНОВИТЬ
Я хочу обновить эту дискуссию, потому что проблема не была решена. Хотя предоставленная ссылка @pravin полезна, она не учитывает тот факт, что у меня есть несколько проектов в одном пакете, а также другое содержимое, такое как сценарии PowerShell, преобразования конфигурации и преобразования исходного кода и т. Д.
Лучший пример, который я могу использовать, - это сборка с версиями.NET 4 и Silverlight 5. Они распространяются в одном пакете. Я не могу использовать событие после сборки для создания пакета, потому что пакет зависит от ДВУХ проектов.
9 ответов
Одна вещь, которая может хорошо работать, - это создание собственного файла MSBuild .proj. Вы можете определить пару целей в пользовательском скрипте, первым выполнив компиляцию в вашем решении. Вторая цель для выполнения следующей компиляции будет использовать задачу EXEC MSBuild для вызова утилиты командной строки nuget.exe. Затем вы обновляете свой пакетный исполняющий файл, чтобы он выполнял исполняемый файл msbuild, предоставляя в качестве аргумента ваш пользовательский файл проекта. Возможно, вы уже используете MSBuild в своем пакетном скрипте, что в этом случае будет просто вопросом обмена аргументами. Вы можете включить свой собственный файл proj в элементы решения вашего решения. Если вы это сделаете, вы можете легко добавить внешнюю ссылку на инструмент в Visual Studio, чтобы быстро протестировать ваш собственный скрипт и убедиться, что он собирает и производит пакет, как вы и надеялись.
Образец MSBuild
Вы можете использовать это как отправную точку:
<Project DefaultTargets="Compile" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
<PropertyGroup>
<SolutionFile></SolutionFile>
<NugetExecutable>C:\PathToNuget\nuget.exe</NugetExecutable>
<NuspecFile></NuspecFile>
</PropertyGroup>
<Target Name = "Compile">
<MSBuild Projects="$(SolutionFile)" Properties="Configuration=Release" />
</Target>
<Target Name = "Package">
<!-- You could use the MSBuild Copy task here to move the compiled code into
a structure that fits your desired package format -->
<Exec Command=""$(NugetExecutable)" pack $(NuspecFile)" />
</Target>
</Project>
Затем вы бы назвали это так:
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe" Build.proj /p:SolutionFile=PathToSolution\App.sln;NuspecFile=foo.nuspec
Я делаю то, что вы хотите достичь уже в моем текущем проекте:
Каждая сборка встроена в свой собственный пакет nuget с установленными зависимостями.
Я решил это, создав папку проекта в проекте, для которого я хотел создать пакет nuget. Там я настраиваю файл nuspec с необходимой информацией о nupkg
Там я создаю все папки и неизменяемые файлы, необходимые для структуры пакета Nuget.
Я добавил шаг посткомпоновки в проект, который копирует только что встроенные файлы в папку пакета и запускает nuget.exe
Такие вот дела:
- Построить проект.
- Скопируйте вывод обратно в Package\Lib проекта.
- Бежать
nuget.exe
с файлом nuspec в папке пакета. - Скопируйте результат в выходную папку рядом с остальными выходными данными.
Nuget.exe должен быть либо в фиксированной папке в вашей системе и на сервере сборки (грязное решение), либо включен в вашу сборку (менее грязную).
Buildscript:
Xcopy.exe /Y "$(TargetPath)" "$(ProjectDir)\Package\Lib"
cd "$(ProjectDir)Package"
"$(TargetDir)..\Buildscripts\Nuget.exe" pack MyPackage.nuspec xcopy /Y *.nupkg "$(TargetDir)"
Чтобы использовать это, единственное, о чем вам нужно позаботиться, - это решить, где проверить nuget.exe. Я создал папку buildscripts на верхнем уровне моего дерева разработки.
Если вы находитесь в среде TFS 2010, проект NuGetter должен решить проблему автоматического создания пакетов nuget. Он создает один пакет для всей сборки. На самом деле это рабочий процесс сборки TFS 2010, который выполняет работу, вызывая nuget.exe с некоторыми аргументами.
Установите пакет NuGet Powertools в свой sln, и он добавит цель сборки для создания nupkg, а затем просто измените ваш CI для выполнения этой задачи. http://nuget.org/packages/NuGetPowerTools
Простое предложение, которое может работать достаточно хорошо... просто поместите его как событие Postbuild в файл.csproj:
<PropertyGroup>
<PostBuildEvent>$(SolutionDir)<YourPathToNugetHere>\NuGet.exe pack $(ProjectPath) -OutputDirectory ..\..\$(OutDir) -IncludeReferencedProjects -Symbols -Properties Configuration=$(Configuration)</PostBuildEvent>
</PropertyGroup>
Это соберет ваш пользовательский файл.nuspec (который должен быть назван как файл.csproj) и соберет.nupkg.
Это оно.
Вы даже можете сделать это просто в настройках проекта Visual Studio.
Существует пакет https://www.nuget.org/packages/CreateNewNuGetPackageFromProjectAfterEachBuild/, который утверждает, что может делать то, что вы хотите. Также есть документация / сайт проекта.
Установите пакет Nuget NuGet.for.MSBuild. Файл '.nuspec' не требуется, и необходимая информация будет взята из AssemblyInfo.cs.
Установите сборку в режим "Release". После сборки файл nupkg будет находиться в папке "bin/Release".
Насколько я знаю, вы не можете.
Вместо этого, сделайте это правильно и создайте правильную среду / процесс сборки, которая запускает скрипт сборки при фиксации / отправке в ваш главный репозиторий, который выполняет следующие действия:
- Клонировать / тянуть изменения.
- Построить решение.
- Построить пакет (ы).
- Загрузите пакет (ы) на сервер пакетов.
Вы можете запустить TeamCity, CruiseControl.NET или другой сервер CI на виртуальной машине или на существующем сервере сборки.