Лучший инструмент для сборки .NET

Возможный дубликат:
NAnt или MSBuild, какой выбрать и когда?

Какой лучший инструмент сборки для .NET?

В настоящее время я использую NAnt, но только потому, что у меня есть опыт работы с Ant . Является ли MSBuild предпочтительным?

Ответов (14)

Решение

Фактически мы используем комбинацию NAnt и MSBuild с CruiseControl . NAnt используется для управления потоком скриптов и вызывает MSBuild для компиляции проектов. После запуска физической сборки NAnt используется для публикации отдельных выходных данных сборки проекта в общем месте.

Я не уверен, что это лучший способ. Я думаю, что многие из нас все еще ищут отличный инструмент для сборки. Одна многообещающая вещь, которую я недавно услышал в выпуске 362 .NET Rocks, - это PSake Джеймса Ковака , система сборки, полностью основанная на PowerShell. Это звучит многообещающе, поскольку возможности PowerShell в теории безграничны.

Я использовал оба и предпочитаю NAnt . Мне действительно трудно сказать, что одно «лучше» другого.

Я использовал как MSBuild, так и NAnt, и я предпочитаю MSBuild, главным образом потому, что по умолчанию он требует гораздо меньше настроек. Хотя вы можете чрезмерно усложнять вещи и загружать MSBuild с большим количеством конфигурационного мусора, в самом простом случае вы можете просто указать его на файл решения / проекта и запустить его, что в большинстве случаев в большинстве случаев является достаточно.

В общем, у меня сложилось впечатление, что NAnt предлагает большую гибкость по сравнению с MSBuild, тогда как (с моими относительно простыми потребностями) меня пока устраивает последний.

Использование динамического языка сценариев, такого как Python, BOO, Ruby и т. Д., Для создания и поддержки сценариев сборки может быть хорошей альтернативой основанному на XML, например NAnt. (Они обычно читаются чище, чем XML.)

Для сборки я использую коммерческое программное обеспечение Automated Build Studio .

UppercuT использует NAnt для сборки, и это безумно простой в использовании Build Framework.

Автоматизированная сборка - это просто: (1) имя решения, (2) путь к системе управления версиями, (3) название компании для большинства проектов!

http://projectuppercut.org/

Вот несколько хороших объяснений: UppercuT

Есть еще один новый инструмент сборки (очень умная оболочка) под названием NUBuild . Он легкий, с открытым исходным кодом, чрезвычайно прост в настройке и обеспечивает практически бесконтактное обслуживание. Мне очень нравится этот новый инструмент, и мы сделали его стандартным инструментом для непрерывной сборки и интеграции наших проектов (у нас около 400 проектов от 75 разработчиков). Попробуйте сами.

http://nubuild.codeplex.com/

  • Простой в использовании интерфейс командной строки
  • Возможность настроить таргетинг на все версии .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#.