Хорошие методы: Как снова использовать .csproj и .sln файлы для создания сценария MSBuild для CI?

Question

Хорошие методы: Как снова использовать .csproj и .sln файлы для создания сценария MSBuild для CI?

Каков безболезненный/удобный в сопровождении способ использовать MSBuild в качестве Вашего бегуна сборки? (Простите длину этого сообщения),

Я просто пробовал силы в TeamCity (который, как я должен сказать, потрясающая w.r.t. кривая обучения и из функциональности поля). Я получил SVN> MSBuild> NUnit> комбинированная работа NCover.

Мне было любопытно относительно того, как умеренный к крупным проектам используют MSBuild - я только что указал на MSBuild на свой Основной sln файл. Я провел некоторое время с NAnt несколько лет назад, и я нашел, что MSBuild был немного тупым. Документы являются слишком плотными/подробными для новичка.

MSBuild, кажется, имеет некоторое специальное волшебство обработать .sln файлы; я попробовал силы в записи сделанного на заказ сценария вручную, связываясь/включая .csproj файлы в порядке (таким образом, что у меня могли быть пользовательские задачи сборки перед сообщением). Однако это подбросило (цитирующий дублирующийся целевой импорт). Я предполагаю, что большая часть devs не хотела бы обходить питание с msbuild proj файлы - они будут вносить изменения в .csproj и .sln файлы. Есть ли некоторый инструмент / задача MSBuild, которая перепроектирует новый сценарий от существующего .sln + его .csproj файлы, о которых я не знаю?

Если я использую MSBuild только, чтобы сделать шаг компиляции, я мог бы также использовать Nant с исполнительной задачей к MSBuild для компиляции решения? У меня есть это нытье, чувствуя, что я пропускаю что-то очевидное.

Моя конечная цель здесь должна иметь сценарий сборки MSBuild

который создает решение
это действует как сценарий сборки вместо шага компиляции. Позволяет пользовательский пред/сообщение задачи. (например, назовите nunit для выполнения nunit проекта (который, кажется, еще не поддерживается через teamcity веб-UI)),
остается вне способа разработчиков, вносящих изменения в решение. Никакое дублирование; не должен требовать, чтобы devs внес то же изменение в 2 местах

7

.net msbuild continuous-integration

задан Gishu 18 June 2010 в 05:03

1 ответ

Другие вопросы по тегам:

.net msbuild continuous-integration

Похожие вопросы:

score 7 · Answer 1

Я еще не пробовал TeamCity, но настроил среду сборки для нашего нового проекта BizTalk.

Следуя прекрасному совету Сайеда Ибрагима Хашими по моему собственному вопросу, прежде чем начать , я создал набор сценариев MSBuild .proj и .targets.

Ядро

Центральный скрипт .targets для фактических шагов сборки, которые вы хотите выполнить:

<Project DefaultTargets="Deploy" xmlns="...">
    <!-- omitted validation steps, see referenced post for details -->
    <PropertyGroup>
        <PullDependsOn>
            $(ValidateDependsOn);
            Validate;
        </PullDependsOn>
    </PropertyGroup>

    <PropertyGroup>
        <BuildDependsOn>
            $(PullDependsOn);
            PullFromVersionControl;
        </BuildDependsOn>
    </PropertyGroup>

    <PropertyGroup>
        <DeployDependsOn>
            $(BuildDependsOn);
            Build;
        </DeployDependsOn>
    </PropertyGroup>

    <Target Name="PullFromVersionControl" DependsOnTargets="$(PullDependsOn)">
        <Exec Command="..." />
    </Target>

    <Target Name="Build" DependsOnTargets="$(BuildDependsOn)">
        <MSBuild Projects="@(ProjectsToBuild)" />
    </Target>

    <Target Name="Deploy" DependsOnTargets="$(DeployDependsOn)">
        <Exec Command="..." />
    </Target>
</Project>

Вторая основная часть - это целевые объекты конфигурации, такие же, как вы находите их в своих файлах .csproj

<Project xmlns="...">
    <PropertyGroup Condition=" '$(Environment)' == 'DEV' ">
        <SomeConfigKey Condition=" '$(SomeConfigKey)' == '' ">Foo</SomeConfigKey>
    </PropertyGroup>

    <PropertyGroup Condition=" '$(Environment)' == 'TEST' ">
        <SomeConfigKey Condition=" '$(SomeConfigKey)' == '' ">Bar</SomeConfigKey>
    </PropertyGroup>
</Project>

Проекты

Единственный .csproj сам по себе представлен файлом.targets, содержащим только набор ItemGroups, которые вам нужны для создания.

<Project xmlns="...">
    <ItemGroup>
        <!-- this group contains the list of items to pull from version control -->
        <Sources Include="@(Sources)" />
        <Sources Include="MyProjectRootDir" />
        <Sources Include="MyDependentProjectRootDir" />
    </ItemGroup>

    <ItemGroup>
        <ProjectsToBuild Include="@(ProjectsToBuild)" />
        <ProjectsToBuild Include="MyProject.csproj" />
    </ItemGroup>
</Project>

Собираем все вместе

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

<Project DefaultTargets="Deploy" xmlns="...">
    <Import Project="Config.targets"/>

    <Import Project="Project.targets"/>

    <Import Project="Core.targets"/>
</Project>

Используя этот подход, я смог повторно использовать .targets, содержащие исходные коды, для создания моих около 50 проектов во многих различных комбинациях вместо создания VS-решений для их группировки.

Надеюсь, вы найдете это полезным - я могу добавить подробности, если вам интересно.