过程模版的定义文件就是上一节说的“XML过程定义文件”中的根文件。就是根目录下的ProcessTemplate.xml文件。
1、ProcessTemplate.xml文件总体介绍
ProcessTemplate.xml文件包含与你的项目有关的三个信息：名称、描述和创建一个项目所要求的插件（包括插件的具体相关信息）。
过程模版的整个目录在上传到Team Foundation Server上的时候，会被压缩（以二进制形式），并存到服务器上。如下图：
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 >
|
|
|
|
插件名 |
依赖关系 |
|
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
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 >的任务连起来。或者是希望实现某种高内聚、低耦合的插件设计吧。具体可能要找到微软的架构师来问了。
其它的字段就不详细介绍了，因为那些字段对工作本身并无任何影响。只是运行时多一些显示信息而已。
5、总结
到这里，我们对ProcessTemplate.xml文件有了一些了解了。由于我们自己现在没写自己的插件。因此只能用目前微软提供的插件，所以以目前现在这个水平阶段，在这里也没什么可以自己配置的。当然，如果有哪位同志想自己把ProcessTemplate.xml中tasklist文件的目录和名字改掉应该也是可以的，不过请你自己记着也把实际的文件夹和配置文件名也改掉，保持一致。
但是如果想自己写插件，那就是属于VSTS扩展应用中的可扩展编程内容了。
注：VSTS扩展应用包含两个方面的内容，一个是VSTS自定义配置扩展，一个是可扩展编程。
尽管如此，我们对过程模版的分工还是有了一定了解。ProcessTemplate.xml果然称得上是根文件。项目创建向导在选择了过程模版之后，第一时间找到目录下的ProcessTemplate.xml文件，ProcessTemplate.xml文件确实相当于程序设计中的声明全局静态变量，把要用的信息全都声明了。然后在groups节中把创建新项目的任务按顺序列出来，这些任务具体怎么做，关联那些插件和文件，通过其tasklist字段中的filename属性，给出一个任务描述的xml文件，在那里做更详细的描述。这样一个任务树就层层展开了。
我们想依靠微软的插件，自己配制真正属于自己想法的模版，就必须要在下面的章节对每个任务组对应的任务文件（xml）做一个一个分析。看看这些具体的任务文件都有什么内容，又是如何展开工作的。
以上有些是本人的猜测，欢迎有了解内幕的兄弟来或不同看法的兄弟来发表意见。