过程模版的定义文件就是上一节说的“XML过程定义文件”中的根文件。就是根目录下的ProcessTemplate.xml文件。
1、ProcessTemplate.xml文件总体介绍

ProcessTemplate.xml文件包含与你的项目有关的三个信息：名称、描述和创建一个项目所要求的插件（包括插件的具体相关信息）。过程模版的整个目录在上传到Team Foundation Server上的时候，会被压缩（以二进制形式），并存到服务器上。如下图：


在TFSIntegration数据库下的Template表。我们可以在TemplateData字段看到整个模版是二进制压缩的。后面还有一个metadate字段存储的是ProcessTemplate.xml文件的metadate节中的信息。为什么要这个字段单独再存一次呢。值得我们好好捉摸。大家可以一起讨论一下。首先看整个ProcessTemplate.xml文件的xsd结构如下图：

可以清晰的看到文件分为两个大的部分 Metadata和groups。下面详细介绍这两个部分。

groups

的作用我认为就是描述如何执行过程模版。
具体功能就下一级结构一样，三个主要作用，一个是描述如何对这些插件分组，一个是描述这些插件之间的依赖关系，一个是描述这些插件该如何运行。其中group节用于描述具体的组内的插件，dependencies节用于描述插件之间的依赖关系，tasklist节用于描述这些插件如何运行。
2、插件是什么

讲了这么久插件是干什么用的呢？
其实，插件的功能就是在你用模版创建新的团队项目的时候从那个压缩好的过程模版中提取指定的工作产品（Word, Excel, Project, 或Visual Studio 文档）、目录、和其它重要的文件。并且按照TaskList节描述的内容进行工作。3、介绍metadata节

metadata的作用我认为就像程序设计时的开始的基本参数声明，全局静态变量。声明了模版的名称、描述和用到的插件的名称。我个人认为微软在数据库中又单独一个字段存储这一块，可能是为了在使用时单独临时生成一个Metadata.xml文件使提取变量声明更加方便。现在编辑ProcessTemplate.xml文件。为你的过程模版添加一个唯一的名字。在文件开始处，metadata节点内，你会发现两个节点：name（名称）和description（描述）。
名称是必须要的元素。
描述是用一小段文字来说明过程模版。现在简单编辑节点验证这两个字段的效果，如下：
 <?xml version="1.0" encoding="utf-8" ?>

    <ProcessTemplate>

    <metadata>

    <name>我的项目管理模版-1.0版</name>

    <description>我的项目管理模版-1.0版.</description>

其余的地方先不动，保存退出XML编辑器，那么我们来上载这个模版看看结果吧。如图：

在模版列表中可以看到新加入的“我的项目管理模版-1.0版”，并且在对话框下面显示了描述信息。再看xml文件，meta字节下还有一个节点：plugins
......
<plugins>
      <plugin name="Microsoft.ProjectCreationWizard.Classification" wizardPage="false"/>
      <plugin name="Microsoft.ProjectCreationWizard.Reporting" wizardPage="false"/>
      <plugin name="Microsoft.ProjectCreationWizard.Portal" wizardPage="true"/>
      <plugin name="Microsoft.ProjectCreationWizard.Groups" wizardPage="false"/>
      <plugin name="Microsoft.ProjectCreationWizard.WorkItemTracking" wizardPage="false"/>
      <plugin name="Microsoft.ProjectCreationWizard.VersionControl" wizardPage="true"/>
    </plugins>
......这个字节是非常重要的，因为它包含了你在过程模版中要求使用的插件的列表，Team System是在这里得到插件的列表信息的。通过 name来定义插件的名字，wizardPage来确定在新团队创建向导中显不显示这个插件的用户控件到向导框中。如果你的过程不需要某个插件，你可以删除对应的plugin节点。如果你想加入自己的插件，就在其中加上一个plugin节点。（关于如何写这些插件的用户控件需要单独写很多，这里就不介绍了，大家也可以一起讨论，这是很有意思的一个话题。）关于每个插件的名字是从何而来的，我仔细找了很久，原先认为就是对应的插件类的命名空间加类名，但是仔细看了SDK里的所有的Team Foundation里的类库，发现这个想法不对。最后在例子中找到，在源程序里通过PluginRegistration属性定义的
定义代码如下：

[PluginRegistration(Catalogs.ProjectCreation, "

插件名称", typeof(插件类名))]

一旦插件名字在这里定义了，以后所有的地方都是调用这个名字。

4、介绍groups节默认的模版里groups组内容如下：
......
<groups>
    <group id="Classification" description="项目的结构定义。" completionMessage="已上载项目结构。">
      <dependencies>
      </dependencies>
      <taskList filename="Classification\classification.xml"/>
    </group>
    <group id="Groups" description="创建组并分配权限。" completionMessage="已创建组并分配权限。">
      <dependencies>
        <dependency groupId="Classification"/>
      </dependencies>
      <taskList filename="Groups and Permissions\GroupsandPermissions.xml"/>
    </group>
    <group id="Portal" description="正在创建项目站点" completionMessage="已创建项目站点。">
      <dependencies>
        <dependency groupId="Classification"/>
        <dependency groupId="WorkItemTracking"/>
        <dependency groupId="VersionControl"/>
      </dependencies>
      <taskList filename="Windows SharePoint Services\WssTasks.xml"/>
    </group>
    <group id="Reporting" description="正在上载项目报告。" completionMessage="已上载项目报告。">
      <dependencies>
        <dependency groupId="Classification"/>
        <dependency groupId="Portal"/>
      </dependencies>
      <taskList filename="Reports\ReportsTasks.xml"/>
    </group>
    <group id="WorkItemTracking" description="正在上载工作项定义。" completionMessage="已上载工作项定义。">
      <dependencies>
        <dependency groupId="Classification"/>
        <dependency groupId="Groups"/>
      </dependencies>
      <taskList filename="WorkItem Tracking\WorkItems.xml"/>
    </group>
    <group id="VersionControl" description="正在创建版本控制。" completionMessage="版本控制任务已完成。">
      <dependencies>
        <dependency groupId="Classification"/>
        <dependency groupId="Groups"/>
        <dependency groupId="WorkItemTracking"/> <!-- This is just to serialize execution with WIT -->
      </dependencies>
      <taskList filename="Version Control\VersionControl.xml"/>
    </group>
  </groups>
......这里有几个元素的内容需要解释。首先要理解什么是group。这个概念很不好理解。要理解清楚，就先看看groups字节内包含了哪些元素。它们都是怎样工作的。

1

）group元素的 id 属性
原先我认为这里的group元素的 id 是和插件的名字或类名有关的，至少与Metadata字节中的plugin的name有关，否则怎么关联这两个字节之间的关系呢，但是经过验证发现居然是无关的，groupid理论上应该可以被任意命名，只要是在groups节点内是唯一的名字就可以了。

2

）<dependencies>
这个字节是描述各个插件之间的依赖关系的，我们知道有些插件需要依赖其余的插件才能运行，特别是安全设定或权限设定需要这样。主要插件的依赖关系如下表： 

插件名	依赖关系
Microsoft.ProjectCreationWizard.Classification	没有依赖项，但是设定项目必须要此插件
Microsoft.ProjectCreationWizard.WorkItemTracking	工作项跟踪插件依赖分类插件和组插件。 工作项插件不是必须插件。（也就是说，你可以使用第三方工作项管理工具来管理你的项目的生命周期）
Microsoft.ProjectCreationWizard.Groups	组插件需要分类插件。 组插件也不是必须的。
Microsoft.ProjectCreationWizard.Reporting	报表插件需要分类和组插件。 它也不是必须的。
Microsoft.ProjectCreationWizard.VersionControl	版本控制插件依赖分类插件。 版本控制插件不是必须的。 （你可以使用第三方版本控制工具并且/或库来管理源代码）
Microsoft.ProjectCreationWizard.Portal	门户插件没有依赖项。 并且在创建一个团队项目的时候也不需要用到它。

请注意这个表是插件的依赖关系，而在xml文件中dependency 字节下并不是写的 plugin的名字而是 group的id。很有意思吧。举例：以下例子中，WorkItemTracking（工作项跟踪）插件依赖的实际上是Classification（分类）插件和Groups（组）插件。但是group id却不用取名和其plugin名字一致。

 <group id="WorkItemTracking"

            description="Workitem definitions uploading."

            completionMessage="Workitem definitions uploaded.">

            <dependencies>

                <dependency groupId="Classification"/>

                <dependency groupId="Groups"/>

            </dependencies>

            <taskList filename="WorkItem Tracking\WorkItems.xml"/>

        </group>

3

）taskList
......
<taskList filename="Windows SharePoint Services\WssTasks.xml"/>
......
其中filename属性是描述具体的group到底做什么的工作描述文件的存放位置。这个位置是一个相对路径。
找到具体的xml文件，打开后我们看到有这样的代码，
......
<task id="SharePointPortal" name="创建 Sharepoint Portal" plugin="Microsoft.ProjectCreationWizard.Portal" completionMessage="已创建项目站点。">
 ......原来plugin在这里出现了。再回顾前几节，我们的模版的目录结构，都在这里得到一一体现。综上所述，我认为对group的正确的理解应该是：所有的插件组都是把每个插件作为一个任务组而组织在一起。具体的说，就是一个group是为一个plugin服务的。在ProcessTemplate.xml文件中，group的id并没有和plugin的name直接关联。而是通过Tasklist中的对应的任务文件，在这个文件中写明对应的插件是什么。为什么这样做，我想可能是微软原先有打算一个group把多个plugin的任务连起来。或者是希望实现某种高内聚、低耦合的插件设计吧。具体可能要找到微软的架构师来问了。

其它的字段就不详细介绍了，因为那些字段对工作本身并无任何影响。只是运行时多一些显示信息而已。5、总结到这里，我们对ProcessTemplate.xml文件有了一些了解了。由于我们自己现在没写自己的插件。因此只能用目前微软提供的插件，所以以目前现在这个水平阶段，在这里也没什么可以自己配置的。当然，如果有哪位同志想自己把ProcessTemplate.xml中tasklist文件的目录和名字改掉应该也是可以的，不过请你自己记着也把实际的文件夹和配置文件名也改掉，保持一致。但是如果想自己写插件，那就是属于VSTS扩展应用中的可扩展编程内容了。注：VSTS扩展应用包含两个方面的内容，一个是VSTS自定义配置扩展，一个是可扩展编程。
尽管如此，我们对过程模版的分工还是有了一定了解。ProcessTemplate.xml果然称得上是根文件。项目创建向导在选择了过程模版之后，第一时间找到目录下的ProcessTemplate.xml文件，ProcessTemplate.xml文件确实相当于程序设计中的声明全局静态变量，把要用的信息全都声明了。然后在groups节中把创建新项目的任务按顺序列出来，这些任务具体怎么做，关联那些插件和文件，通过其tasklist字段中的filename属性，给出一个任务描述的xml文件，在那里做更详细的描述。这样一个任务树就层层展开了。我们想依靠微软的插件，自己配制真正属于自己想法的模版，就必须要在下面的章节对每个任务组对应的任务文件（xml）做一个一个分析。看看这些具体的任务文件都有什么内容，又是如何展开工作的。

以上有些是本人的猜测，欢迎有了解内幕的兄弟来或不同看法的兄弟来发表意见。