Непрерывная интеграция проектов .NET: NAnt и/или MSBuild?

[NorthernEyes]

Я бы лучше от NAnt перешёл сразу к Psake.

[kekekeks]

А оно под *nix-системами уже работать научилось?

[ForNeVeR]

Мы работаем над этим.

[unlocker]

Насчет необходимости изучения PowerShell исключительно для сборки проектов меня терзают смутные сомнения. Ну, а весёлые пародии из PS на утилиты Unix полностью отбивают желание его изучать.

NAnt под Mono уже уже работает.

[jonie]

у msbuild (я еще не ковырял пререлизную студию, хотя наверно она врядли что-то исправит) починили проблему с неподдержкой тагретов, в имени которых есть точка (подробнее)?

[xunter]

Добавлю 5 копеек для собирающихся делать CI, что лучше Unit-тесты сразу писать используя NUnit, чем MSTest, потому что последнего нет, как standalone-решения и он есть только с Visual Studio или TFS, а если мы используем на Build-сервере Jenkins или TeamCity, то у нас не будет возможности запускать unit-тесты. Вот.

[kekekeks]

Ещё лучше взять xUnit, он более правильно спроектирован и создаёт отдельный экземпляр класса на каждый тест.

[alexanderzaytsev]

Я тоже раньше так думал.

[Gwynbleidd]

А развейте тему, пожалуйста. Интересно.

[alexanderzaytsev]

Когда вышел xUnit.net это был небольшой прорыв (читать тут: xunit.codeplex.com/wikipage?title=WhyDidWeBuildXunit&referringTitle=Home), но с тех пор он топчется на месте и никакого развития нет.

Для меня, в то время, главными фичами были:

1. Assert.Throws вместо [ExpectedException]

Это позволяло видеть, где произошло исключение, и делать больше проверок над исключением. Со временем эта фича появилась и в NUnit.

2. отдельный экземпляр класса на каждый тест.

Это было приятным бонусом, и то не всегда, к примеру, вы уже не можете использовать xUnit.net как средство интеграционного тестирования, с толстой настройкой.
NUnit тут предоставляет бОльшую гибкость:
— общий контекст на несколько тестовых сценариев;
— общий контекст на несколько тестов;
— хотите экземпляр класса на тест — делайте классы с единственным методом

При этом NUnit развился дальше, к примеру, в нем появились fluent-assertions, а xUnit.net остался там же.

[ETman]

пост, конечно, старый, но может кто-то его прочитает и не поймет, что то, о чём вы говорите, реализовано в xUnit с помощью Fixtures. На счет fluent-assertions не в курсе.

[CrazyViper]

Вы не правы в отношении TeamCity. Он умеет запускать MSTest. Мы в своем проекте используем MSTest и сборка идет на TeamCity.

Вот скриншот настройки конфигурации:

[xunter]

На Build-сервере Visual Studio установлена? какая версия?

[CrazyViper]

Да, установлена 2012 проф. Действительно, тимсити видимо находит установленный движок и использует его.

[unlocker]

TeamCity запускает тесты, если указан путь к установленному MSTest. Установка MSTest, по умолчанию, равносильна установке Visual Studio.

Инструкции по отделению тестового движка от VS есть тут.

Мы запускали MSTest так:

<Target Name="Test" DependsOnTargets="Build"> 
    <CreateItem Include="$(TmpOutputPath)\*Test.dll"> 
        <Output TaskParameter="Include" ItemName="TestAssembly" /> 
    </CreateItem> 
        <Message Text="@(TestAssembly)"/> 
    <MakeDir Directories="$(ReportPath)"/> 
	<PropertyGroup> 
	    <MsTestCommand></MsTestCommand> 
	</PropertyGroup> 
	<Exec Command='"$(MSTEST_HOME)\mstest.exe" /testcontainer:@(TestAssembly) /resultsfile:"$(ReportPath)\TestResult.trx"' IgnoreExitCode="true"/>  
</Target>

Того же эффекта можно достичь, используя MSBuild Extension Pack.

[mayorovp]

Работа с файлами по маскам позволяет нам минимизировать объём работы по поддержке единожды написанных скриптов.

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

Наследование свойств между проектами позволяет нам не заботиться о явной передаче всех значений между проектами разных уровней. Например, легко организовать сбор всех результатов компиляции в одной папке на уровне Solution вместо размножения папок bin, obj в каждом отдельном проекте.

В TFS такие свойства, как выходной каталог, прекрасно наследуются вдоль всей цепочки. Я уже забыл, как это было сделано, но такая возможность в msbuild точно есть.

Императивность работы NAnt позволяет легко модифицировать отдельные target'ы проектов по своему усмотрению. Реализация типовой задачки: скопировать помимо библиотек еще и пару самодельных конфигов при помощи BeforeBuild и AfterBuild событий (внутри них не используются задачи MSBuild, а обычно используются cmd- или Powershell-скрипты) смотрится «костыльной» по сравнению с явным использованием родной задачи NAnt copy.

Хм, но кто мешает использовать родную для msbuild задачу copy в тех самых местах?

MSBuild ищет dll с зависимостями там, где они должны были оказаться после сборки проектов-зависимостей

Ну… да. Правда, если решить проблему с наследованием свойств, то эта проблема перестанет быть проблемой, поскольку dll с зависимостями окажутся именно там, где их будет искать msbuild.

Кроме того, никто не мешает перегрузить цели GetTargetPath, GetNativeManifest и GetCopyToOutputDirectoryItems — для уточнения «экспортируемой» информации, и ResolveAssemblyReferences — для поиска зависимостей в соответствии со своими пожеланиями.

Итог: при заголовке «Непрерывная интеграция проектов .NET: NAnt и/или MSBuild?» я ожидал увидеть статью «подробное сравнение NAnt и MBuild», а увидел «Историю о том, как я не смог разобраться с MSBuild». Тоже интересный результат, но мне он уже не поможет.

[unlocker]

В TFS такие свойства, как выходной каталог, прекрасно наследуются вдоль всей цепочки. Я уже забыл, как это было сделано, но такая возможность в msbuild точно есть.

Давайте не мешать французское с нижегородским. TFS и MSBuild вещи немного разные. У нас в команде не получилось нормально передавать кастомные свойства (версии 3.5 и 4.0), например, полностью квалифицированный номер сборки, кроме как прямой передачей при вызове файла targets. Во-вторых, места агрегации dll, msi и отчетов по тестам разные. Как это нормально оформить в MSBuild?

Ещё один интересный аспект — это работа версии MSBuild x64. Непонятно каким образом, но многие дополнительные task'и не работают в этой версии. Ярким примером можно привести Wix.

Но главный недостаток для меня лично — это невозможность в одном скрипте и загружать, и использовать task'и.

Я не хочу навязывать один инструмент. Мне интересен опыт сообщества по допиливанию функционала «из коробки» под собственные весьма специфичные условия.

[mayorovp]

Давайте не мешать французское с нижегородским. TFS и MSBuild вещи немного разные

Фокус в том, что TFS делает это при помощи стандартных средств MSBuild.