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

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

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

Я просто хотел бы добавить FinalBuilder в эту смесь. Это не бесплатно, но если вы сыты по горло редактированием файлов XML и хотите работать в несколько более приятной среде ( IMO), я бы дал ей шанс.

Я работал со всеми ними и всегда возвращался к FinalBuilder.

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

http://nubuild.codeplex.com/

• Простой в использовании интерфейс командной строки
• Возможность направлять все рамки .NET версии, то есть 1.1, 2.0, 3.0 и 3.5
• Поддерживает конфигурацию на основе XML
• Поддерживает как проект, так и файл Рекомендации
• Автоматически генерирует “complete ordered build list” для данного проект - нет сенсорного обслуживания.
• Возможность обнаружения и отображения циклическая зависимость
• Выполнение параллельной сборки - автоматически решает, какой из проекты в созданном списке сборки может быть построен самостоятельно.
• Возможность обработки прокси-сборок
• Предоставляет визуальный ключ к сборке процесс, например, показывает “% завершено”, “текущее состояние"и т.д.
• Создает подробный журнал выполнения обоих в XML и текстовом формате
• Легко интегрируется с CruiseControl.NET непрерывного интеграционная система
• Можно использовать пользовательский регистратор, как XMLLogger при таргетинге на версию 2.0 +
• Возможность разбора журналов ошибок
• Возможность развертывания построенных сборок в указанное Пользователем место
• Возможность синхронизации исходного кода с системой управления исходным кодом
• Возможность управления версиями

Я использую 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-это место, где происходит вся конфигурация и все может быть настроено, например, исключение определенных проектов из сборки или добавление новых масок теста assembly.

ItemGroup - это место, где происходит логика, которая находит все файлы .csproj в дереве.

Затем есть цели, которые большинство людей, знакомых с make, nAnt или MSBuild, должны уметь выполнять. Если вы называете целевой объект build, он вызывает __компиляции, __развернуть и __тест. Чистый целевой объект вызывает MSBuild для всех файлов проекта, чтобы они очистили свои каталоги, а затем удаляется глобальный каталог deployment. Восстановить вызовы, очистить, а затем построить.

Рейк и Альбакор-отличное сочетание. Сила Ruby и нет XML.

.NET открытым исходным кодом 5 - автоматизация .NET с граблями и длинноперого Лиам McLennan [Tekpub.com]

Мы используем Bounce, фреймворк для более чистых сценариев сборки в C#.

Мы используем MSBuild, потому что мы начали с Visual Studio 2005 (теперь Visual Studio 2008), и MSBuild уже были "built in" до SDK - там меньше обслуживания на сервере сборки. На самом деле это клон NAnt - оба инструмента бесконечно гибки в том, что они позволяют создавать пользовательские задачи сборки в коде, и оба имеют приличный набор уже созданных задач сборки сообщества.

• MSBuild Задачи Сообщества
• NAntContrib

Я использую коммерческое программное обеспечение, автоматизированную студию сборки для целей сборки.

Я использовал оба варианта и предпочитаю NAnt . Мне действительно трудно сказать, что один из них "better", чем другой.

Это также зависит от того, что вы строите. Библиотека задач MSBuild SDC имеет несколько специальных задач. Например, для AD , BizTalk и т. д.

Есть более 300 задач, включенных в эта библиотека включает в себя задачи для: создание сайтов, создание пулы приложений, создание ActiveDirectory пользователей, работающих под управлением FxCop , настройка виртуальных серверов, создание zip файлов, настройка COM+, создание общие папки, устанавливаемые в GAC, настройка SQL сервера , настройка BizTalk 2004 и BizTalk 2006 и др.

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

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

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

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

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

http://projectuppercut.org/

Некоторые хорошие объяснения здесь: UppercuT