Лучший инструмент для сборки .NET
Возможный дубликат:
NAnt или MSBuild, какой выбрать и когда?
Какой лучший инструмент сборки для .NET?
В настоящее время я использую NAnt, но только потому, что у меня есть опыт работы с Ant . Является ли MSBuild предпочтительным?
Ответов (14)14
Фактически мы используем комбинацию NAnt и MSBuild с CruiseControl . NAnt используется для управления потоком скриптов и вызывает MSBuild для компиляции проектов. После запуска физической сборки NAnt используется для публикации отдельных выходных данных сборки проекта в общем месте.
Я не уверен, что это лучший способ. Я думаю, что многие из нас все еще ищут отличный инструмент для сборки. Одна многообещающая вещь, которую я недавно услышал в выпуске 362 .NET Rocks, - это PSake Джеймса Ковака , система сборки, полностью основанная на PowerShell. Это звучит многообещающе, поскольку возможности PowerShell в теории безграничны.
Я использовал оба и предпочитаю NAnt . Мне действительно трудно сказать, что одно «лучше» другого.
Я использовал как MSBuild, так и NAnt, и я предпочитаю MSBuild, главным образом потому, что по умолчанию он требует гораздо меньше настроек. Хотя вы можете чрезмерно усложнять вещи и загружать MSBuild с большим количеством конфигурационного мусора, в самом простом случае вы можете просто указать его на файл решения / проекта и запустить его, что в большинстве случаев в большинстве случаев является достаточно.
Для сборки я использую коммерческое программное обеспечение Automated Build Studio .
UppercuT использует NAnt для сборки, и это безумно простой в использовании Build Framework.
Автоматизированная сборка - это просто: (1) имя решения, (2) путь к системе управления версиями, (3) название компании для большинства проектов!
Вот несколько хороших объяснений: UppercuT
Есть еще один новый инструмент сборки (очень умная оболочка) под названием NUBuild . Он легкий, с открытым исходным кодом, чрезвычайно прост в настройке и обеспечивает практически бесконтактное обслуживание. Мне очень нравится этот новый инструмент, и мы сделали его стандартным инструментом для непрерывной сборки и интеграции наших проектов (у нас около 400 проектов от 75 разработчиков). Попробуйте сами.
- Простой в использовании интерфейс командной строки
- Возможность настроить таргетинг на все версии .NET Framework, то есть 1.1, 2.0, 3.0 и 3.5.
- Поддерживает конфигурацию на основе XML
- Поддерживает ссылки как на проекты, так и на файлы
- Автоматически генерирует «полный список упорядоченных сборок» для данного проекта - без обслуживания.
- Возможность обнаружения и отображения циклических зависимостей
- Выполнять параллельную сборку - автоматически решает, какие из проектов в сгенерированном списке сборки могут быть построены независимо.
- Возможность обрабатывать сборки прокси
- Предоставляет визуальную подсказку к процессу сборки, например, показывая «% завершено», «текущий статус» и т. Д.
- Создает подробный журнал выполнения как в XML, так и в текстовом формате
- Легко интегрируется с системой непрерывной интеграции CruiseControl.NET
- Может использовать настраиваемый регистратор, такой как XMLLogger, при таргетинге на версию 2.0 и выше.
- Возможность разбирать журналы ошибок
- Возможность развертывания собранных сборок в указанном пользователем месте
- Возможность синхронизации исходного кода с системой управления версиями
- Возможность управления версиями
Грабли и Альбакор - отличное сочетание. Сила Ruby и никакого XML.
.NET с открытым исходным кодом 5 - Автоматизация .NET с помощью Rake и Albacore, автор Лиам МакЛеннан [Tekpub.com]
Мы используем MSBuild, потому что мы начали с Visual Studio 2005 (теперь Visual Studio 2008), а MSBuild уже был «встроен» в SDK - меньше обслуживания на сервере сборки. На самом деле это клон NAnt - оба инструмента бесконечно гибки в том смысле, что они позволяют вам создавать собственные задачи сборки в коде, и оба имеют приличный набор уже созданных задач сборки сообщества.
Я просто хотел бы добавить FinalBuilder в микс. Это не бесплатно, но если вам надоело редактировать XML- файлы и вы хотите, чтобы работала несколько более приятная ( IMO ) среда, я бы попробовал.
Я работал со всеми из них и всегда возвращался к FinalBuilder.
Это также зависит от того, что вы строите. В библиотеке MSBuild SDC Task есть несколько специальных задач. Например, для AD , BizTalk и т. Д.
В эту библиотеку включено более 300 задач, включая задачи для: создания веб-сайтов, создания пулов приложений, создания пользователей ActiveDirectory, запуска FxCop , настройки виртуальных серверов, создания zip-файлов, настройки COM + , создания общих папок, установки в GAC , настройки SQL Server. , настройка BizTalk 2004 и BizTalk 2006 и т. д.
Я полностью использую MSBuild для сборки. Вот мой общий сценарий MSBuild, который ищет в дереве файлы .csproj и строит их:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<UsingTask AssemblyFile="$(MSBuildProjectDirectory)\bin\xUnit\xunitext.runner.msbuild.dll" TaskName="XunitExt.Runner.MSBuild.xunit"/>
<PropertyGroup>
<Configuration Condition="'$(Configuration)'==''">Debug</Configuration>
<DeployDir>$(MSBuildProjectDirectory)\Build\$(Configuration)</DeployDir>
<ProjectMask>$(MSBuildProjectDirectory)\**\*.csproj</ProjectMask>
<ProjectExcludeMask></ProjectExcludeMask>
<TestAssembliesIncludeMask>$(DeployDir)\*.Test.dll</TestAssembliesIncludeMask>
</PropertyGroup>
<ItemGroup>
<ProjectFiles Include="$(ProjectMask)" Exclude="$(ProjectExcludeMask)"/>
</ItemGroup>
<Target Name="Build" DependsOnTargets="__Compile;__Deploy;__Test"/>
<Target Name="Clean">
<MSBuild Projects="@(ProjectFiles)" Targets="Clean"/>
<RemoveDir Directories="$(DeployDir)"/>
</Target>
<Target Name="Rebuild" DependsOnTargets="Clean;Build"/>
<!--
===== Targets that are meant for use only by MSBuild =====
-->
<Target Name="__Compile">
<MSBuild Projects="@(ProjectFiles)" Targets="Build">
<Output TaskParameter="TargetOutputs" ItemName="AssembliesBuilt"/>
</MSBuild>
<CreateItem Include="@(AssembliesBuilt -> '%(RootDir)%(Directory)*')">
<Output TaskParameter="Include" ItemName="DeployFiles"/>
</CreateItem>
</Target>
<Target Name="__Deploy">
<MakeDir Directories="$(DeployDir)"/>
<Copy SourceFiles="@(DeployFiles)" DestinationFolder="$(DeployDir)"/>
<CreateItem Include="$(TestAssembliesIncludeMask)">
<Output TaskParameter="Include" ItemName="TestAssemblies"/>
</CreateItem>
</Target>
<Target Name="__Test">
<xunit Assembly="@(TestAssemblies)"/>
</Target>
</Project>
(Извините, если он немного плотный. Markdown, похоже, удаляет пустые строки.)
Это довольно просто, если вы понимаете концепции и все зависимости обрабатываются автоматически. Я должен отметить, что мы используем файлы проектов Visual Studio, в которые встроено много логики, но эта система позволяет людям строить почти идентично как в среде Visual Studio IDE, так и в командной строке, и при этом дает вам гибкость при добавлении вещей. к канонической сборке, такой как тестирование xUnit, которое вы видите в приведенном выше скрипте.
Одна PropertyGroup - это место, где происходит вся конфигурация и что-то может быть настроено, например, исключение определенных проектов из сборки или добавление новых масок тестовой сборки.
ItemGroup - это то место, где происходит логика, которая находит все файлы .csproj в дереве.
Затем есть цели, которым должно следовать большинство людей, знакомых с make, nAnt или MSBuild. Если вы вызываете цель сборки, она вызывает __Compile, __Deploy и __Test. Целевой объект Clean вызывает MSBuild для всех файлов проекта, чтобы они очистили свои каталоги, а затем глобальный каталог развертывания удаляется. Rebuild вызывает Clean, а затем Build.
Мы используем Bounce , фреймворк для более чистых сценариев сборки на C#.