MSBuild简单介绍

背景

---

托博客园的福，上周六，有家开发医疗行业系统的初创公司联系我，说在博客园上看到我关于WPF的几篇文章，邀请我去他们那里交流WPF相关的技术知识和心得体会。作为非大拿的我自然是受宠若惊，但对方好意相约，我便欣然前往。

诸事按过不表，在交流过程中，谈到了单独一个产品的版本控制的问题。

（以下该公司人员简称为对方）

对方：“我们用SVN，还不错。只是现在产品的版本越来越多。”

我：“怎么说？”

对方：“我们开发平台有2.0、4.0，目前正在尝试4.5，特性和语法还是有些许不一样的。但是我们不可能为每个.net framework单独维护一个解决方案。少数不同的地方，我们采用SVN分支的方式进行。”

我：“你们产品的市场版本应该也有若干个吧……”

对方：“唔，客户的需求大同小异，所以我们的版本是按模块和功能的不同而区分的，比如标准版、决策分析版、旗舰版等等，但每个版本具体到某个模块，基本上保持一致，偶尔需要微调下。”

我：“微调也是通过SVN来管理？”

对方：“是的，所以现在分支越来越多，其实代码都大同小异。”

我：“哦，我没理解错的话，很多情况下，当主干代码修改了，那所有的这些分支都需要进行相应的合并？”

对方：“是这样没错，有时候想想，如果主干修改的内容能自动无错地合并到分支就好了。”

我：“SVN我只会简单使用，不过我认为你们的这种情况，可以使用另一种方式——vs原本就支持的……”

说到这里，对方的眼睛突然亮了，我和他相视一笑，我知道他也想到了。这也暗合了我自己总结的一套哲理中的其中一条：汝握秘之钥，just forget it。而这么显而易见的处理方法被整个开发团队忽略，这是一个典型的“群体性失明”案例。

“MD，早该想到，条件编译符号！”

没错，条件编译符号结合#if、#else、#endif之类，恰当地使用它们，可以将SVN的各个分支重新整合在一起（当然并行开发过程仍然需要SVN进行管控）。前提是各分支不要有太大差异，有些分支项目结构都变了，那更没必要整在一起了。

各位看官，是不是有点疑惑——不是说MSBuild吗，怎么扯到条件编译符号上去了？

隔天晚上，我正在安装前几天卸载掉的快播软件，准备用来观看这两天落下的新闻联播时，手机响了，是上面那家公司的技术主管（以下仍称对方）。在这个关键时刻打我电话，肯定是发生了紧急的事情，于是我淡定地按了接听键。

对方：“XX，我们用WPF版本的项目做整合，发现有个问题。”

我：“不会吧，什么问题？”

对方：“代码文件没问题，通过条件编译符号能生成特定版本的程序集，但是xaml文件似乎并不支持#if、#elif这些指令。”

我一惊：“what？！”

对方：“某些情况，我们通过binding方式，就是说，在代码文件中根据编译符号设置某一属性的值，然后前台根据这个值来显示特定版本的内容。但是另外有些情况不晓得怎么处理。电话说不清楚，我发你QQ。”

挂了电话，我不情愿地中止了快播安装进程，打开QQ，一段代码跳了出来。

 1 
 2 <his:SmartGridView AutoGenerateColumns="True"                   
 3                    Title="{Binding Title}"
 4                    ItemsSource="{Binding GridDataItems}">
 5     
 6     <his:SmartGridView.RowDetailsTemplate>
 7         <DataTemplate>
 8             <his:MedicineStockDetailsTemplate />
 9         DataTemplate>
10     his:SmartGridView.RowDetailsTemplate>
11     
12 his:SmartGridView>

对方表示第6行到第10行是目前难点所在。我半晌之后回过神，确实，编译指令+条件编译符号对cs文件有用，在xaml中能结合binding达到一部分效果，当遇到一段xaml要么存在，要么不存在的情况，这三者就无能为力了。怎么办？

我查阅头脑中的知识库，无果，上网搜索也没搜出个所以然来，难道又要怪微软这个坑爹货，不在xaml中加入预编译指令这么拉轰的功能？正当拙计之时，猛然发现有个单词在谷歌的怀抱中向我抛着媚眼，定睛一看——“MSBuild”！

 基本概念

---

MSBuild基于项目文件发挥作用。我们以Visual C# 项目文件为例。当在Visual Studio中新建一个项目，VS自动给我们生成了一个.csproj项目文件。一个典型的项目文件格式如下：

 1 <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
 2   <PropertyGroup>
 3     <AssemblyName>MSBuildSampleAssemblyName>
 4     <OutputPath>Bin\OutputPath>
 5   PropertyGroup>
 6   <ItemGroup>
 7     <Compile Include="helloworld.cs" />
 8   ItemGroup>
 9   <Target Name="Build" Inputs="@(Compile)" Outputs="$(OutputPath)$(AssemblyName).exe">
10     <MakeDir Directories="$(OutputPath)" Condition="!Exists('$(OutputPath)')" />
11     <Csc Sources="@(Compile)" OutputAssembly="$(OutputPath)$(AssemblyName).exe" />
12   Target>
13   <Target Name="Clean" >
14     <Delete Files="$(OutputPath)$(AssemblyName).exe" />
15   Target>
16   <Target Name="Rebuild" DependsOnTargets="Clean;Build" />
17 Project>

• 其中PropertyGroup定义各种属性键值对，类似于字符串变量；
• ItemGroup定义各种项，项可以有元数据（MetaData），我们可以将之看作对象（class），一般用于定义文件/文件夹；
• Target，目标，其中一般包含若干Task，针对生成程序集这个过程来讲，Target即为执行一系列任务完成的一个生成步骤，当预定的所有生成步骤都完成之后，程序集也就生成成功了。
• 以$(PropertyName)方式获取属性值；
• @(ItemType)语法引用项，直接打印为Include指定的字符串，要获取项的元数据，使用%(ItemType.MetaDataName)；
• 可以将项列表转换为新的项列表。语法：@(ItemType -> '%(MetadataName)')。当然右边可以是任意你想要的格式，可以使用属性、函数或自定义字符串等等；
  
• Target中设置Inputs和Outputs属性将改变该步骤为增量模式，即MSBuild会比对这两者之间最晚的文件修改时间以决定是否执行该步骤；
• Target中的DependsOnTargets表示该Target依赖于其它Target，其它Target执行完毕之后该Target才能执行，且其它Target的执行顺序为DependsOnTargets中定义的顺序。
• 另外，几乎所有MSBuild元素都可以有Condition特性，只有当Condition的计算结果为“true”时，才会定义或重新定义相关元素。

假设上述文件保存为Test.csproj，我们可以在Visual Studio 命令提示键入

msbuild Test.csproj /t:Rebuild

/t表示要执行的Target，若去除/t:Rebuild，则会执行Build Target，因为Project节点有个DefaultTargets，指定了默认的Target。

以上为基本概念，详情请参看：演练：使用 MSBuild

进阶

---

1. 有些系统预定义的Target.前边说道vs会帮我们自动生成一个项目文件,用记事本打开看,会发现Project的DefaultTargets="Build",但是文件中并未定义名称为"Build"的Target,这就是系统预定义的。另外末尾有两个被注释掉的Target,在Build Target执行前后要做些额外事情,我们就可以使用它们.
2. 项（Item）也有很多预定义的元数据，比如Filename、Extension、FullPath，从字面就能理解它们的意思，具体请看MSBuild: By Example—Introducing Well-Known Metadata;
3. 也有若干保留属性，参考MSBuild 保留属性；
4. 在 .NET Framework 4 版和 4.5 版中，可以使用属性函数来计算 MSBuild 脚本。参考属性函数；
5. 动态创建项.有时候需要根据已有条件创建新项,比如在磁盘中动态生成了一些文件,我们就可以为这些文件创建对应的项,以便使之有机会参与Build的过程.注意项Include特性指向的文件如果不存在,在生成过程中可能会抛出error导致生成中止.3.5之前,可以使用CreateItem;3.5及以后版本对这方面做了改进,可以直接在Target中嵌入ItemGroup,不但能创建新Item,还能Remove或者Modify原有的Item.参考CreateItem vs ItemGroup;
   
6. 前边说过Target里包含若干Task,表示按顺序执行的步骤,咱们也可以自定义Task.比如自定义了一个Task名称为PreprocessXaml,它包含在BuildTasks.dll的程序集中,可以使用以下方式获得该Task的引用.

   1 <PropertyGroup>
   2   <BuildTasksPath Condition="'$(BuildTasksPath)' == ''">..\BuildTasks\BuildTasksPath>
   3   <BuildTasksLib>$(BuildTasksPath)BuildTasks.dllBuildTasksLib>
   4 PropertyGroup>
   5 
   6 <UsingTask AssemblyFile="$(BuildTasksLib)" TaskName="PreprocessXaml" />

   然后可以这么使用之.

   <Target Name="MyTarget">
     <PreprocessXaml SourceFile="%(PreprocessedXaml.FullPath)"
                                   DestinationFile="$(ProjectDir)%(PreprocessedXaml.OutputFile)">
     PreprocessXaml>
   Target>

   更多参考Best Practices For Creating Reliable Builds, Part 2;

7. 第1条说道我们可以在项目文件末尾取消默认注释掉的两个Target,在其中插入我们想要在Build之前之后执行的逻辑.当然还有另一种方法,覆盖预定义的BuildDependsOn属性.

   <PropertyGroup>
     <BuildDependsOn>
       MyBeforeTarget;
       $(BuildDependsOn);
       MyAfterTarget;
     BuildDependsOn>
   PropertyGroup>

   还有其它预定义东东可以覆盖,更多详情:如何：扩展 Visual Studio 生成过程;

8. 除了在项目文件中写一份完整的MSBuild文档,还可以将之分离成多个.targets格式文件，targets文档格式同.csproj/.vbproj文件.then我们可以在项目文件中使用引入,targets文件也能引入其它targets,MSBuild根据引入顺序执行生成过程;
9. 生成过程如果出错,就会终止,而使用vs不能像普通项目一样进行运行时调试.往往出错都是出自自定义Task,Task有个Log对象,我们可以使用它在vs底部的错误列表中输出错误\警告\普通消息.如base.Log.LogErrorFromException(exception);　　

使用MSBuild给XAML增加条件编译符号的支持

---

概念方面,算是基本把该写到的点都写到，哎,累了,特别是这种相对枯燥的概念学习、解释、搬运，刚开始根本无从下手，各种繁杂困惑。接下去就是完成咱们最初的目的。大家先自己思考下怎么个方案可行。这下篇再写吧。刚说了，哥累了。

 

转载请注明本文出处：http://www.cnblogs.com/newton/p/3156873.html