MSBuild的深入认识

最近在从事自动构造工作的过程中，对MSBuild本身有了一些更加深入的认识。MSBuild不仅仅是一个构造工具，应该称之为拥有相当强大扩展能力的自动化平台。

按照笔者现在的理解，MSBuild平台的主要涉及到三部分：执行引擎、构造工程、任务。其中最核心的就是执行引擎，它包括定义构造工程的规范，解释构造工程，执行“构造动作”；构造工程是用来描述构造任务的，大多数情况下我们使用MSBuild就是遵循规范，编写一个构造工程；MSBuild引擎执行的每一个“构造动作”就是通过任务实现的 ，任务就是MSBuild的扩展机制，通过编写新的任务就能够不断扩充MSBuild的执行能力。

所以这三部分分别代表了引擎、脚本和扩展能力。

1、构造工程（脚本文件）

先说说构造工程，只要通过Notepad打开任何一个VS2005（也就是支持CLR 2.0）下的C#工程（csproj）文件，就知道构造工程到底是怎么回事了。

如果说脚本，我们立刻想到的是VBScript或者JavaScript，构造工程内描述的内容，和常见的脚本语言的源文件之间还是有蛮大差距的，为什么也称之为“脚本”呢？因为笔者觉得没啥区别。脚本不就是纯文本形式保存，不经编译解释执行，可以实现一定逻辑分支的程序么？

再看构造工程，在构造工程中我们我们可以定义和使用变量（通过Property/PropertyGourp/Item/ItemGroup等元素），可以使用条件分支（通过Choose/When/Otherwise等元素）、能够在运行时给变量赋值（通过执行任务，获取其返回类型参数的方式）、能够定义执行块（通过Target元素，相当于函数）、能够进行异常处理（通过OnError元素）、还可以复用已有工程定义的内容（通过Import元素）。拥有这些能力和高级语言已经相差无几了，所以笔者认为构造工程不是描述性语言，而是脚本语言。

这里还需要强调一点的是，项目级元素（Property）可以在<PropertyGroup>元素下定义，也可以在构造过程中作为外部参数传入（具体参见《MSBuild命令行参考》）。这是一个非常有用的特性，一般编译时选择配置项（Debug或者Release）就是利用这个特性实现的。

有关构造工程的编写规范可以参考《MSBuild项目文件引用》。

2、执行引擎

接下来看执行引擎，通常我们使用下面的命令行开始执行构造：

MSBuild.exe <ProjectFile>

其中<ProjectFile>是前面提到的构造工程，也就是脚本文件，那么MSBuild.exe就应当是执行引擎了。

没错，不过看一下源代码就会发现MSBuild.exe非常简单，其实主要做的工作就是命令行解析、构造环境的准备（如生成日志记录模块准备一些全局变量），然后就是创建Microsoft.Build.BuildEngine.Engine类的实例，然后调用其BuildProjectFile方法来完成。所以真正的构造逻辑是在Microsoft.Build.Engine.dll中定义并且实现的。下面简单的代码就模拟了MSBuild.exe的工作。

using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Build.BuildEngine;
 
namespace BuildAProjectCS
{
    class Program
    {       
        static void Main(string[] args)
        {
            // Instantiate a new Engine object
            Engine engine = new Engine();
            // Point to the path that contains the .NET Framework 2.0 CLR and tools
            engine.BinPath = @"c:\windows\microsoft.net\framework\v2.0.xxxxx";
            // Instantiate a new FileLogger to generate build log
            FileLogger logger = new FileLogger();
            // Set the logfile parameter to indicate the log destination
            logger.Parameters = @"logfile=C:\temp\build.log";
            // Register the logger with the engine
            engine.RegisterLogger(logger);
            // Build a project file
            bool success = engine.BuildProjectFile(@"c:\temp\validate.proj");
            //Unregister all loggers to close the log file
            engine.UnregisterAllLoggers();
            if (success)
                Console.WriteLine("Build succeeded.");
            else
                Console.WriteLine(@"Build failed. View C:\temp\build.log for details");
        }
    }
}

具体的对象模型参见CLR类库参考中的《Microsoft.Build.Framework命名空间》和《Microsoft.Build.BuildEngine命令空间》。

笔者简单地分析了一下MSBuild.exe和Microsoft.Build.Engine.dll的源代码，MSBuild的构造过程大致如下：

a) 先创建一个构造请求（BuildRequest，构造请求是用来记录构造状态的数据结构），创建完毕之后将构造请求投递到请求队列中。

b) 在执行模块中，从请求队列中获取请求，然后开始处理。

c) 通过Project类加载构造工程，加载过程中检查是Sulotion、VC工程还是其它语言的工程。如果是Solution的话，生成一个临时的包装工程，逐一构造Solution中包含的工程；如果是VC工程的话，也生成一个包装工程，在这个工程中直接执行VCBuild任务来执行构造。否则直接通过XmlDocument加载项目文件，解析其中的元素，识别Property、Item、Target之类元素。

d) 工程解析完毕后按照Target的顺序逐一执行。

e) 在执行Target的过程中先解析是否存在依赖的Target以及OnError子句（即产生错误时需要执行的Target）。

f) 先执行Target依赖的Target，然后通过TaskEngine执行本Target中的每一个任务。如果Target每一个任务都正确执行的话，那么执行下一个Target；否则执行错误处理的Target。

g) 执行Task的过程就是实例化注册为Task的类，然后调用其Execute方法。

h) 所有Target执行完毕，则本次构造也执行完毕。

以上仅仅为了便于理解概念进行的描述，实际的构造过程可能是考虑到多CPU以及内联编译，内部逻辑相当复杂，很多地方应用了Proxy模式。

3、任务（Task）

通过对执行引擎的描述可以发现执行引擎主要是维护执行流程以及记录执行流程中各类变量（Property和Item），具体构造过程中的每一个动作，都是通过Task实现的。也就是说单靠Microsoft.Build.Engine.dll虽然可以加载并且解析构造工程，但是无法完成构造动作。之所以MSBuild能够完成编译、链接、创建目录、复制文件等一系列工作，都是因为在Microsoft.Build.Tasks.dll中实现了与之对应的一个个任务。具体请参考《MSBuild任务参考》以及CLR类库参考中的《Microsoft.Build.Task命名空间》

通过观察MSBuild自带的这些常用任务，可以发现其中分为两类：一类从ToolTask继承，这类任务基本上就是直接调用外部二进制文件执行完成某个特定的动作，例如VCBuild和Exec等；另一类直接从Task继承，是通过内部代码逻辑完成特定动作，例如Copy和MSBuild等。那些直接执行外部文件的任务虽然功能强大，但是有比较大的局限性，执行结果的反馈非常有限，通常只有ExitCode，很难获得其内部执行的更多信息，例如日志输出或者操作影响的结果。

大部分情况下我们只需要一个Exec任务就能够完成全部的构造动作，但是这样做的结果和我们写一个命令行的批处理文件没什么区别了。MSBuild平 台和命令行批处理最大不同在于，它是一个更紧密的工作环境，任务之间通过一系列自定义的全局参数互相协同工作，比较灵活并且移植性高；同时共享日志模块统 一输出执行过程中的各类信息，便于观察和分析。而批处理中各个命令之间几乎是完全孤立的，只能通过硬编码的方式进行协同，协作能力比较差。

举个最简单的例子，编译三个工程，然后复制编译结果到目标目录下。如果用批处理可能会写成这个样子：“编译工程1、复制编译结果、编译工程2、复制结果、编译工程3、复制结果”。而利用MSBuild就可以简化很多工作，例如“申明需要编译的工程（工程1、工程2、工程3、...）、编译需要编译的工程、复制编译结果”。

顺便说一句，MSBuild这个任务比较有趣，在内部直接调用了构造引擎的方法（IBuildEngine2.BuildPrejectFilesInParallel）。这个例子又一次告诉我们这个世界上许多看似强大的东西，其实什么都没有干，只是因为他们手中掌握了有效的资源。-^o^-

除了基础的任务之外，任务还可以任意扩展，并且实现这种扩展非常方便。创建一个CLR 2.0以上的类库工程，编写实现了ITask接口的类，然后在构造工程中通过<UsingTask>元素注册任务就可以使用了。例如：

<UsingTask
TaskName="Microsoft.CompactFramework.Build.Tasks.PlatformVerificationTask"
AssemblyName="Microsoft.CompactFramework.Build.Tasks, Version=9.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
……
<Target Name="PlatformVerificationTask">
<PlatformVerificationTask PlatformFamilyName="$(PlatformFamilyName)"
PlatformID="$(PlatformID)" SourceAssembly="@(IntermediateAssembly)"
ReferencePath="@(ReferencePath)"
TreatWarningsAsErrors="$(TreatWarningsAsErrors)"
PlatformVersion="$(TargetFrameworkVersion)"/>
</Target>

所以说MSBuild能够成为一个构造引擎，不是因为有个叫MSBuild的Exe文件，也不是因为脚本文件被称之为构造工程，而是因为与之配套的Microsoft.Build.Task.dll中主要实现了主要是和构造相关的任务。换句话说如果提供和测试相关的任务库的话，MSBuild也就是一个自动测试的平台。

总之，MSBuild本身更趋向于一个自动化执行平台，可以根据需求编写不同的脚本文件来满足不同的应用，当现有能力无法满足时，通过编写新的任务进行扩展。不仅限于构造，自动安装、自动测试等都可以依赖这个平台来实现。