良好实践:如何重用 .csproj 和 .sln 文件来为 CI 创建 MSBuild 脚本?

问题描述

使用 MSBuild 作为构建运行器的轻松/可维护方式是什么?(请原谅这篇文章的长度)

What is the painless/maintainable way of using MSBuild as your build runner ? (Forgive the length of this post)

我只是在 TeamCity 中尝试一下(我必须说，学习曲线和开箱即用的功能非常棒).我有一个 SVN > MSBuild > NUnit > NCover 组合工作.

I was just trying my hand at TeamCity (which I must say is awesome w.r.t. learning curve and out of the box functionality). I got an SVN > MSBuild > NUnit > NCover combo working.

我很好奇中型到大型项目如何使用 MSBuild - 我刚刚将 MSBuild 指向了我的 Main sln 文件.几年前我在 NAnt 上花了一些时间，我发现 MSBuild 有点迟钝.对于初学者来说，文档过于密集/详细.

I was curious as to how moderate to large projects are using MSBuild - I've just pointed MSBuild to my Main sln file. I've spent some time with NAnt some years ago and I found MSBuild to be a bit obtuse. The docs are too dense/detailed for a beginner.

MSBuild 似乎有一些特殊的魔法来处理 .sln 文件；我尝试手动编写自定义构建脚本，按顺序链接/包含 .csproj 文件(这样我可以有自定义的 pre-post build 任务).但是它抛出了(引用重复的目标导入).我假设大多数开发人员不想搞乱 msbuild proj 文件 - 他们会更改 .csproj 和 .sln 文件.是否有一些工具/MSBuild 任务可以从我不知道的现有 .sln + 其 .csproj 文件对新脚本进行逆向工程?

MSBuild seems to have some special magic to handle .sln files ; I tried my hand at writing a custom build script by hand, linking/including .csproj files in order (such that I could have custom pre-post build tasks). However it threw up (citing duplicate target imports). I'm assuming most devs wouldn't want to go messing around with msbuild proj files - they'd be making changes to the .csproj and .sln files. Is there some tool / MSBuild task that reverse-engineers a new script from an existing .sln + its .csproj files that I'm unaware of ?

如果我使用 MSBuild 只是为了执行编译步骤，我还不如将 Nant 与 MSBuild 的 exec 任务一起使用来编译解决方案?我有一种挥之不去的感觉，我错过了一些明显的东西.

If I'm using MSBuild just to do the compile step, I might as well use Nant with an exec task to MSBuild for compiling the solution ? I've this nagging feeling that I'm missing something obvious.

我的最终目标是拥有一个 MSBuild 构建脚本

My end-goal here is to have a MSBuild build script

• 构建解决方案
• 充当构建脚本而不是编译步骤.允许自定义前置/后置任务.(例如，调用 nunit 来运行一个 nunit 项目(似乎还没有通过 teamcity Web UI 支持)
• 不妨碍开发人员对解决方案进行更改.没有冗余；不应要求开发人员在 2 个地方进行相同的更改

推荐答案

我还没有尝试 TeamCity，但确实为我们的新 BizTalk 项目设置了构建环境.

I didn't try TeamCity yet but did set up a Build environment for our new BizTalk project.

遵循 Sayed Ibrahim Hashimi 在 在开始之前我自己的问题，我创建了一组 MSBuild .proj 和 .targets脚本.

Following the excellent advice of Sayed Ibrahim Hashimi on my own question before starting out, I created a set of MSBuild .proj and .targets scripts.

核心

您要执行的实际构建步骤的中央 .targets 脚本:

A central .targets script for the actual build steps you want to perform:

<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 文件中找到的配置目标

The second core part are the configuration targets like you find them in your .csproj files

<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 集合.

The single .csproj itself is represented by a.targets file with just a collection of ItemGroups you need for building.

<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>

放在一起

您将使用 MSBuild 实际执行的 .proj 将导入您的配置、您的项目(源代码文件)和核心(拉取、构建和部署命令)

The .proj you are actually going to execute with MSBuild will import your Configuration, your Project (source code files) and the Core (Pull, Build and Deployment commands)

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

    <Import Project="Project.targets"/>

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

使用这种方法，我能够重用包含源代码的 .targets，以多种不同的组合构建我的大约 50 个项目，而不是创建 VS 解决方案来对它们进行分组.

Using this approach I was able to reuse the .targets containing the sources to build my some 50 projects in many different combinations instead of creating VS solutions to group them.

我希望你会发现这很有用 - 如果你有兴趣，我可以添加更多详细信息.

I hope you'll find this useful - I can add more details if you're interested.

这篇关于良好实践:如何重用 .csproj 和 .sln 文件来为 CI 创建 MSBuild 脚本?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！