DEV332 Visual Studio Team Foundation Server 客户化与可扩展性分析

DEV332 Visual Studio Team Foundation Server 客户化与可扩展性分析

课程内容概述随着大量企业应用Visual Studio 2005 Team Foundation Server，几乎所有的企业面都需要对Team Foundation Server进行一定的客户化。其中，还有部分企业需要对Team Foundation Server进行一定的扩展，以适应这些企业的特点。本专题总结了我们在企业中实施Team Foundation Server的一些经验，着重分析与客户化和可扩展性相关的内容。本课程适于有意向使用Team Foundation Server的企业客户。

课程内容安排 Visual Studio Team System 概述 Team Foundation Server 概述
Team Build Server 客户化

Visual Studio Team System 概述
4 © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Visual Studio Team Suite Visual Studio Team Foundation Server
Visual Studio Team System Visual Studio Team Suite 软件架构师开发人员测试人员数据库专业人员 Visual Studio 团队浏览器 Visual Studio 工业合作伙伴应用建模代码分析 Web测试变更管理部署建模性能测试负载测试数据库测试安全分析测试用例管理数据库部署单元测试代码分析 MSF 过程指导类图 Visio与UML 建模 Visual Studio 专业版负载测试代理 Visual Studio Team Foundation Server 配制管理变更管理自动报告工作项跟踪协作站点项目管理

Visual Studio Team System
初级标准高级加速级需求 -即兴 -文档化 -基本文档模板 -工具 -可跟踪性 -多层次 -SLA -影响分析 -商业可视化 -平台管理 -KPI/SLA 架构设计 -建模工具 -可重用性 -SOA -设计模式 -基础设施验证评估过程 -无 -瀑布型 Agile/SCRUM/ 等. -迭代型 -CMMI -可重复性 -以过程为中心配制管理变更管理 -文件 - -不集成的 -基本工具 -协作工具 -全球性/并行开发 -策略管理 -高度集成的配制管理 -配制管理策略质量保证测试 -开发测试 -专职QA人员 -自动测试工具 -系统测试 -团队协作/工具集成 -集成的测试环境 -虚拟化操作 -手工基本脚本 -自动 -部署策略 -监控 -优化报告 -状态报告项目管理工具 -多项目/ 跨项目 -商务智能 IT兼容性无可调查可审计

Team Foundation Server 概述

Visual Studio Team System
开发人员测试人员项目经理应用架构师 VSTE/ST 部署架构师 VSTE/SD Office产品 VSTE/SA Team Foundation Server 高层管理人员配置管理构建服务器浏览器工作项团队站点可扩展的平台集成的工具方法论的指导自动报表

Team Foundation Object Model (Managed API)
Team Foundation Server 架构 Office System MS Excel Plug-in MS Project VS Packages Visual Studio Command Line … Team Foundation Object Model (Managed API) Reports Web Parts WSS IE … Team Project Portal Site SQL Reporting Services Team Foundation Data Services Source Code Control Service Work Item Service Build Data Services Registration Service Eventing and Notification Service Linking Service Team Foundation Integration Services MSSQL/TCP SOAP / HTTP(S) ASP.NET Team Foundation Data-Tier Methodology SCC WI (Product Studio) Build Data Warehouse Build Results Test Results Code Coverage Static Analysis SQL

Team Foundation Server 客户化

Team System 过程模板现有的模板第三方模板自定义 MSF For Agile Software Development
MSF For CMMI® Process Improvement 第三方模板 Osellus BrightWorks Conchango (Scrum) Congnizant (Feature Driven Development) 自定义独立定义新的过程模板扩展现有的过程模板 Explain why you would want to customize a process template? Here are some common examples: A company has an existing process that can loosely match an existing template. The company would want to incorporate their unique terms, definitions workflow and include their custom documents and document templates. A company is rolling out a new process specific to a type of SDLC in their organization, for example a wave of VB6 to .Net migrations is about to happen, so the project management team wants to implement some specific policies and practices that would only apply to these projects.

过程模板客户化现在当前的过程模板客户化过程模板上载新的过程模板用新的模板创建团队项目团队项目正确生成 No 直接对工作项
进行客户化删除测试团队项目 Yes

过程模板XML文件 <ProcessTemplate> <metadata>
<name>My Process</name> <description>Process description</description> <plugins> <plugin name="Microsoft.ProjectCreationWizard.Classification“ wizardPage="false" /> </plugins> </metadata> <groups> <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> <groups> </ProcessTemplate> Locate the ProcessTemplate.xml file in the root folder and open it with NotePad. For this demonstration, change the Template’s Name and description.

工作项类型 <WORKITEMTYPES>
<WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Bug.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Task.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Qos.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Scenario.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Risk.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Defect.xml"/> </WORKITEMTYPES> Locate the workitems.xml file in the WorkItem Tracking folder. Open it with notepad and within notepad, locate the section that contains the various work item types. Copy the bug WORKITEMTYPE and paste it into the WORKITEMTYPES section with the name Defect.

Plug-ins Classifications Work Items Windows SharePoint Services
Version Control Reports Group Security Service The Process Template Wizard uses a pluggable architecture. The Project Creation Wizard uses a extensible plug-in model and you may create your own plug-in, but this will not be covered here. For the next section of slides, you should refer back to the downloaded process template to show actual examples.

剖析过程模板 ProcessTemplate.xml WSS Windows SharePoint Document Library
Reports Report Definitions Classifications Areas and Iterations Definitions Groups and Permissions Initial Security Groups and Permissions Version Control XML Process Definition Files The XML process definition files are a set of XML files that define a set of tasks that must run to properly configure a new team project for the process. When the New Team Project wizard creates a team project, it runs the required plug-ins. Each plug-in reads its corresponding XML process definition file to obtain the list of tasks it needs to run. Using the XML process definition files, you specify what configurations and settings the plug-ins must implement. ProcessTemplate.xml is the root XML file that defines the entire process template and all subordinate XML files. The ProcessTemplate.xml file contains all of the task groups that must run to successfully create a team project. Each task group references a subordinate XML file (often in a subfolder) where the specific tasks are defined. In general, you specify one task group for each plug-in. When creating or customizing a process template, there are four key sections to complete in the ProcessTemplate.xml file. Name Use the name element to define a process template name. This is required, and the name is displayed in the process template list in the New Team Project wizard, and in the Process Template Manager dialog box. <name>Simple Process</name> Description Use the description element to provide a description of the process template. This text is displayed on the Select a Process Template screen in the New Team Project wizard when a project lead or administrator is deciding which process template to use. In general, try to describe what kinds of projects the process template is useful for in terms of team size, length, cost, and other factors. <description>Choose the simple process for projects that require little or no overhead and have very low cost.</description> Plugins The plugins element lists all of the plug-ins used by the process template. You must make sure that if any subordinate XML file is referencing a plug-in, that same plug-in appears in this list. You must also specify the wizardPage attribute (a true or false value) to indicate if the plug-in requires a page on the New Team Project wizard. The following XML shows the correct values to use for each plug-in. <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> Task Groups The task groups identify sets of tasks that will run. Generally there is one task group per plug-in, and this is the easiest model to follow. The following example shows how a task group creates the project structure. The specific tasks are defined in the referenced file (Classification.xml). <group id="Classification" description="Structure definition for the project." completionMessage="Project Structure uploaded."> <dependencies> </dependencies> <taskList filename="Classification\Classification.xml"/> </group> The following table describes each of the elements in a task group. ElementDescriptionidIdentifies the task group. If another task group is dependent on this group, it will reference this id.descriptionDescribes what the task group does.completionMessageDisplays a message to the user if the task group completes successfully. The message is displayed during team project creation.dependencySpecifies the id of another task group that this group is dependent on. The other group must complete before this group can start.taskListIdentifies an XML file that contains the list of tasks to run. The list of tasks for a group must always be in a separate XML file. Tasks A task specifies work that must occur to configure something specific to the process in a new team project. Tasks can perform work such as create a new work item type, add a report, copy a file to the project portal, and configure a security group. For example, the following XML shows a task that creates all of the work item types by referencing the work item type definition files: <task id="WITs" name="WorkItemType definitions" plugin="Microsoft.ProjectCreationWizard.WorkItemTracking" completionMessage="WorkItemTypes created" completionDescription = "Processing work item types used by work item tracking"> <taskXml> <WORKITEMTYPES> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Bug.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Task.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Qos.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Scenario.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Risk.xml"/> </WORKITEMTYPES> </taskXml> </task> The following table describes each of the elements in a task. ElementDescriptionidIdentifies the task. If another task is dependent on this task, it will reference this id.nameDescribes what the task does.pluginIdentifies which plug-in must run this task.completionMessageDisplays a message to the user if the task completes successfully. The message is displayed during team project creation.completionDescriptionDisplays a description while the task is in process. The description is displayed during team project creation.dependencySpecifies the id of another task that this task is dependent on. The other task must complete before this task can start.taskXmlContains information describing the work that must take place to complete this task. The XML inside this element block varies and is specific to each plug-in. Dependencies A task can be dependent on other tasks, requiring other tasks to complete before it can run. For example, the task to create work item instances cannot run until all of the tasks to create work item types have run. Therefore the work item instances task is dependent on the work item type tasks. Use the dependency element in tasks and groups to indicate when a dependency exists. The following example shows how to use the dependency element to specify that the WorkItemTracking task group is dependent on the Classification and Groups task groups. <group id="WorkItemTracking" description="Workitem definitions uploading." completionMessage="Workitem definitions uploaded."> <dependency groupId="Classification"/> <dependency groupId="Groups"/> <taskList filename="WorkItem Tracking\WorkItems.xml"/> Note: The groupId element references the id element value in the other group. The following example shows how to use the dependency element to specify that the WorkItems task depends on the WITs task. id="WIs" name="WorkItems" completionMessage="Work items uploaded" completionDescription = "Processing the actual work items used by work item tracking"> <dependency taskId="WITs" /> ... Tip List your tasks in each XML process definition file in the same order as their dependencies. This will make it easier to eliminate any dependency problems, and easier to read. Some plug-ins are always dependent on other plug-ins. Also, not all plug-ins are required for a process template. The following table identifies which plug-ins are dependent on other plug-ins, and whether or not they are required to be in a process template. Initial Version Control Permissions Work Item Work Item Type and Query Definitions Bug.xml Task.xml …

Classifications Plug-In
Microsoft.ProjectCreationWizard.Classification 默认的定义: Classification\Classification.xml 目的: 定义过程的 Iteration 定义项目的 Area 定义与MS Project的映射关系 Classification\FileMapping.xml Classification Plug-in The Classification plug-in controls the iterations and structure of a team project. The plug-in name is Microsoft.ProjectCreationWizard.Classification. The Classication XML file is named Classification.xml and is located in the Classification folder in the process template folder hierarchy. You can change the XML file and folder name if necessary. In the XML file, specify 1 or more tasks and their dependencies. In general, you only need one task to specify all the iterations and nodes required for a team project. For an example of a task specifying iterations, see the Classifications.xml file in the MSF for Agile Software Development process template. Iterations The iterations you define for a process determine how many times the team will repeat a particular set of major activities (such as plan, develop, test). Iterations affect work item queries and reports because iterations are used to group work items. For example, a team member can query for all bug work items from iteration 1. Iterations appear in the System.IterationPath field for any work items that reference this field. You must specify the root node for iterations using the following syntax. <Node StructureType="ProjectLifecycle" Name="Iteration" xmlns=""> Then specify 0 or more children nodes for as many iterations as you need for your process. Use the Node element to specify each iteration. You must set the StructureType attribute to ProjectLifecycle. The following example shows how to specify 4 iterations: Milestone 1, Milestone 2, Beta, and RTM. <?xml version="1.0" encoding="utf-8" ?> <tasks> <task id="UploadStructure" name="Creating project structure" plugin="Microsoft.ProjectCreationWizard.Classification" completionMessage="Portfolio project structure created."> <taskXml> <Nodes> <Children> <Node StructureType="ProjectLifecycle" Name="Milestone 1"></Node> <Node StructureType="ProjectLifecycle" Name="Milestone 2"></Node> <Node StructureType="ProjectLifecycle" Name="Beta"></Node> <Node StructureType="ProjectLifecycle" Name="RTM"></Node> </Children> </Node> ... </Nodes> </taskXml> </task> </tasks> Areas Areas represent key groups on the team project. For example, a team could organize the product work such that there is a client area, server area, and extensibility area. Areas are used to group work items for queries and reports. Areas appear in the System.AreaPath field for any work items that reference this field. You must specify the root node of areas using the following syntax. <Node StructureType="ProjectModelHierarchy" Name="Area" xmlns=""> Then specify 0 or more children nodes for as many areas as you need for your process. Use the Node element to specify each area. You must set the StructureType attribute to ProjectModelHierarchy. <Node StructureType="ProjectModelHierarchy" Name="" xmlns=""></Node> The following example shows how to specify 2 areas: Client and Server. <Node StructureType="ProjectModelHierarchy" Name="Teams" xmlns=""> <Node StructureType="ProjectModelHierarchy" Name="Client"></Node> <Node StructureType="ProjectModelHierarchy" Name="Server"></Node> Warning: If you modify a process template's iterations or areas, ensure that you do not break any work item instance tasks in workitems.xml. Work item instances may reference specific iterations or areas. Specifying Microsoft Project Field Map Properties The Classification plug-in also defines field mappings between work item types and Microsoft Project. Unlike Microsoft Excel, Microsoft Project uses a limited set of columns including predefined columns such as Task Name, and custom fields. When a user publishes or refreshes work item data in a Microsoft Project file, the field map is used to determine which fields in the work item database match the columns in Microsoft Project. You can customize the mappings, for example to support a new field that you created, or to map fields to predefined columns instead of custom columns. Note After a team project is created, the field mappings cannot be changed for that team project. The field map is located in an XML file named FileMapping.xml. Classification.xml must contain an entry referencing the FileMapping.xml file as shown in the following example. <properties> <property name="MSPROJ" value="Classification\FileMapping.xml" isFile="true" /> </properties> In FileMapping.xml, specify mapped fields using the Mapping element. <Mappings> <Mapping WorkItemTrackingFieldReferenceName="System.Id" ProjectField="" ProjectName=""/> </Mappings> The following describes the attributes for the Mapping element. WorkItemTrackingFieldReferenceName: Specifies the reference name of a work item type field. ProjectField: Specifies the name of a Microsoft Project column. Specify predefined column names by prefixing “pj” to the name, such as pjTaskName for the Task Name column. Specify custom fields as pjTaskText followed by a number, such as pjTaskText11. ProjectName: Specifies the name to display as the column name to the user. The following example shows how the MSF for Agile Software Development process template maps work item fields to Microsoft Project. <?xml version="1.0" encoding="utf-8"?> <MSProject> <Mapping WorkItemTrackingFieldReferenceName="System.Id" ProjectField="pjTaskText10" ProjectName="Work Item ID"/> <Mapping WorkItemTrackingFieldReferenceName="System.Title" ProjectField="pjTaskName" /> <Mapping WorkItemTrackingFieldReferenceName="System.WorkItemType" ProjectField="pjTaskText24" /> <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Common.Discipline" ProjectField="pjTaskText17" /> <Mapping WorkItemTrackingFieldReferenceName="System.AssignedTo" ProjectField="pjTaskResourceNames" /> <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Scheduling.CompletedWork" ProjectField="pjTaskActualWork" ProjectUnits="pjHour"/> <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Scheduling.RemainingWork" ProjectField="pjTaskRemainingWork" ProjectUnits="pjHour"/> <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Scheduling.BaselineWork" ProjectField="pjTaskBaselineWork" ProjectUnits="pjHour"/> <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Scheduling.StartDate" ProjectField="pjTaskStart" PublishOnly="true"/> <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Scheduling.FinishDate" ProjectField="pjTaskFinish" PublishOnly="true"/> <Mapping WorkItemTrackingFieldReferenceName="System.State" ProjectField="pjTaskText13" /> <Mapping WorkItemTrackingFieldReferenceName="System.Reason" ProjectField="pjTaskText14" /> <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Common.Rank" ProjectField="pjTaskText16" /> <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Common.Issue" ProjectField="pjTaskText15" /> <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Common.ExitCriteria" ProjectField="pjTaskText20" /> <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Common.QualityOfServiceType" ProjectField="pjTaskText21" /> <Mapping WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Common.Priority" ProjectField="pjTaskText19" ProjectName="Work Item Priority" /> <Mapping WorkItemTrackingFieldReferenceName="System.AreaPath" ProjectField="pjTaskOutlineCode9" /> <Mapping WorkItemTrackingFieldReferenceName="System.IterationPath" ProjectField="pjTaskOutlineCode10" /> <Mapping WorkItemTrackingFieldReferenceName="System.Rev" ProjectField="pjTaskText23" /> <ContextField WorkItemTrackingFieldReferenceName="Microsoft.VSTS.Scheduling.TaskHierarchy"/> <LinksField ProjectField="pjTaskText26" /> <SyncField ProjectField="pjTaskText25" /> </MSProject> There are two special columns in the mapping field list. One is the synchronization field, which specifies which column serves as the synchronization field. The synchronization field is titled “Publish and Refresh” and allows the user to indicate if a task row is published or refreshed only. Use the following XML syntax to specify which column maps to the synchronization field. The ProjectField attribute must be set to a valid Microsoft Project column. <SyncField ProjectField="" /> The other special field is the links and attachments field. The links and attachments column allows users to indicate if there are links or attachments for a particular task row. Use the following XML syntax to specify which column maps to the links and attachments field. The ProjectField attribute must be set to a valid Microsoft Project column. <LinksField ProjectField="" /> Verification You can verify that the Classification plug-in creates the iterations and areas correctly by creating a new team project and following these steps: In Team Explorer, right-click the new team project and choose Team Project Settings, Areas and Iterations. In the Areas and Iterations dialog box, select the Area tab and ensure that each area appears correctly. Select the Iteration tab and ensure that each iteration appears correctly.

Classifications 例子 <?xml version="1.0" encoding="utf-8" ?>
<tasks> <task id="UploadStructure" name="Creating project structure" plugin="Microsoft.ProjectCreationWizard.Classification" completionMessage="Portfolio project structure created."> <taskXml> <Nodes> <Node StructureType="ProjectLifecycle" Name="Iteration" xmlns=""> <Children> <Node StructureType="ProjectLifecycle" Name="Iteration 0"></Node> <Node StructureType="ProjectLifecycle" Name="Iteration 1"></Node> <Node StructureType="ProjectLifecycle" Name="Iteration 2"></Node> </Children> </Node> <Node StructureType="ProjectModelHierarchy" Name="Area" xmlns=""></Node> </Nodes> <properties> <property name="MSPROJ" value="Classification\FileMapping.xml" isFile="true" /> </properties> </taskXml> </task> </tasks>

Work Item Plug-In Plug-In 名称: 默认定义: 目的:
Microsoft.ProjectCreationWizard.WorkItemTracking 默认定义: WorkItems Tracking\workitems.xml 目的: 定义工作项的初始类型和查询通过过程模板向导创建工作项实例 Work Item Tracking Plug-in The Work Item Tracking Plug-in defines a team project's initial work item types, queries, and work item instances. The plug-in name is Microsoft.ProjectCreationWizard.WorkItemTracking. The Work Item Tracking XML file is named workitems.xml and is located in the Work Item Tracking folder in the process template folder hierarchy. You can change the schema file and folder name if necessary. In the XML file, specify 1 or more tasks and their dependencies. There are 3 key types of tasks to specify: work item types, work item queries, and work item instances. Work Item Types A work item type defines the rules, fields, states, and transitions for an item of work that will be tracked on a team project (that is, bugs, requirements, and risks). The work item type is specified in a type definition XML file in the TypeDefinitions folder (under the Work Item Tracking folder). For example, MSF for Agile Software Development defines Bug, Quality of Service (QoS), Scenario, Risk, and Task work item types in the files Bug.xml, QoS.xml, Scenario.xml, Risk.xml, and Task.xml respectively. Customize or create new type definition files in the TypeDefinitions folder. For more information on creating or customizing work item types, see the Authoring Work Item Types Lab and related documents in this extensibility kit. To include the work item types in the process template, you must create one or more tasks in the workitems.xml file. Use the WORKITEMTYPE element to specify the correct type definition file. The filename attribute is a relative path to the work item type definition file. <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\filename.xml"/> The following example shows how to specify a task that creates all five work item types in MSF for Agile Software Development. <task id="WITs" name="WorkItemType definitions" plugin="Microsoft.ProjectCreationWizard.WorkItemTracking" completionMessage="WorkItemTypes created" completionDescription = "Processing work item types used by work item tracking"> <taskXml> <WORKITEMTYPES> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Bug.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Task.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Qos.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Scenario.xml"/> <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Risk.xml"/> </WORKITEMTYPES> </taskXml> </task> Work Item Queries A work item query can be run by team members to find specific groupings of work items (such as all risks, or active bugs). Work item queries are specified in work item query (WIQ) files in the Queries folder (under the Work Item Tracking folder). For example, MSF for Agile Software Developmenht defines the Active Bugs query which is specified in the ActiveBugs.wiq file. The easiest way to create work item query files is in Team Explorer. In an existing Team Project, use Team Explorer to create all of the work item queries you need for your process. Then use the following procedure to save each work item query to a .wiq file. In Team Explorer, right-click the query and choose View Query. From the File menu, choose Save <name of query> As. In the Save Query As dialog box, choose the File option, and enter a location and filename for the WIQ file. Click the Save button. Copy the file to the Work Item Tracking\Queries folder of your process template. Note: You must edit the WIQ file and remove the TeamFoundationServer and TeamProject elements that associate the query with a specific Team Foundation Server and team project. Otherwise the query will not work properly if the process template is uploaded to a different Team Foundation Server. To include the work item queries in the process template, create one or more tasks in the workitems.xml file. Use the Query element to specify the correct work item query file. <Query name="Active Bugs" fileName="WorkItem Tracking\Queries\filename.wiq" /> The following example shows how to specify a task that creates the All Scenarios work item query in MSF for Agile Software Development. Note that the task cannot run until all the work item types are created. id="Queries" name="Stored Query Definitions" completionMessage="Queries uploaded" completionDescription = "Processing the stored queries used by work item tracking"> <dependencies> <dependency taskId="WIs" /> <dependency taskId="WITs" /> </dependencies> <QUERIES> <Query name="All Scenarios" fileName="WorkItem Tracking\Queries\AllScenarios.wiq" /> ... </QUERIES> Work Item Instances When a team project is created, you can specify an initial set of work item instances that are already created when team members begin working. MSF Agile creates an initial set of tasks that serve as the project checklist to guide project leads and the team. To specify work item instances, use the WI and FIELD elements. <WI type=""> <FIELD refname="" value="" /> </WI> The type attribute for the WI element specifies which work item type is being created, such as bug, scenario, or risk. You must provide one or more FIELD elements to specify the field values for the work item. The FIELD element has two attributes explained in the following list. Refname: The reference name of the field to set Value: The value to set in the field. The following example shows how to create a work item instance that is a task work item type. The name of the work item is Setup: Set Permissions. Note that required field values are provided. id="WIs" name="WorkItems" completionMessage="Work items uploaded" completionDescription = "Processing the actual work items used by work item tracking"> <WORKITEMS> <WI type="Task"> <FIELD refname="System.Title" value="Setup: Set Permissions" /> <FIELD refname="System.IterationPath" value="$$PROJECTNAME$$\Iteration 0" /> <FIELD refname="System.State" value="Active" /> <FIELD refname="System.Reason" value="New" /> <FIELD refname="Microsoft.VSTS.Common.Issue" value="No" /> <FIELD refname="Microsoft.VSTS.Common.ExitCriteria" value="Yes" /> <FIELD refname="System.Description" value="Using the admin UI in VS add users to one of the 3 groups: Project administrators, Contributors or Readers." /> </WORKITEMS> Verification You can verify that the queries and type definitions you specified are created correctly by creating a new team project based on your custom process template, and following these steps: In Team Explorer, expand the Work Items node on the new team project. Right click the Work Items node, and choose a menu option that creates one of your work item types. In the work item form for the new work item, check that all the fields appear correctly. Update the work item by moving it through each state, and ensure that fields work as expected for each state. Repeat steps 1 through 4 for each work item type. In Team Explorer, expand the Project Queries node. Ensure that each query is present. Right-click a query and choose View Results. Ensure that the results are as expected and that they have the proper columns. Repeat steps 6 and 7 for each query. Run a query to return all work items. Ensure that all of the work item instances you specified are present.

Windows SharePoint Services Plug-In
Microsoft.ProjectCreationWizard.Portal 默认定义: WSS\WssTasks.xml 目的: 基于SharePoint Site Template定义项目的Portal 文档库和文件夹结构文档模板定义并安装Process Guidance Windows SharePoint Services Plug-in The Windows SharePoint Services plug-in defines the project portal for the team based on a SharePoint site template. The plug-in name is Microsoft.ProjectCreationWizard.Portal. The Windows SharePoint Services XML file is named WssTasks.xml and is located in the Windows SharePoint Services folder in the process template folder hierarchy. You can change the XML file and folder name if necessary. In the XML file, specify 1 or more tasks and their dependencies. There are 3 key tasks to specify: which site template to use, which document libraries to create, and which folders and files to copy into the document libraries. For an example of tasks specifying a simple project portal, see the WssTasks.xml file in the MSF for Agile Software Development process template. Site Template You must specify a site template that the project portal is based on. The site template also must be available on the Team Foundation Server SharePoint Portal. Site templates are not included in the process template. Specify the site template using the site element. <site template="" language=""/> The following table describes the attributes for the site element. Template: Specifies which template to use. The template is a combination of the template name and configuration id from the webtemp.xml file on the SharePoint server. Language: Specifies a locale id indicating which language version of the site template to use. The English version is 1033. The following example shows how to reference the English version of template VSTS_MSFAgile. <task id="SharePointPortal" name="Create Sharepoint Portal" plugin="Microsoft.ProjectCreationWizard.Portal" completionMessage="Project site created."> <dependencies/> <taskXml> <Portal> <site template="VSTS_MSFAgile" language="1033"/> ... Note All other Windows SharePoint Services tasks are dependent on this task because the project portal must be created before you create additional document libraries or copy files. Creating custom site templates You can create custom SharePoint site templates for use with process templates. SharePoint site templates are created using the administrative features on the SharePoint site. For more information on creating SharePoint site templates, see the Microsoft Windows SharePoint Services 2.0 Help. After you create a custom SharePoint site template, you must add it to any Team Foundation Server where it will be used. First save the custom site template to a file. It will have a .stp file extension. For more information on saving site templates, see the Microsoft Windows SharePoint Services 2.0 Help. You can use the SharePoint site to add custom site templates, or you can use the command prompt. The following procedure explains how to add a custom site template to Team Foundation Server. To add a custom site template to Team Foundation Server On the Team Foundation Server, open a command prompt window. At the command prompt, change to the \Program Files\Common Files\Microsoft Shared\web server extensions\60\bin directory. Type the following command to add the custom site template to Team Foundation Server. stsadm -o addtemplate -filename <custom site template filename>.stp -title <site template title> Type iisreset and press Enter. IIS must be restarted so that the added site template is available. Once custom site templates are uploaded to Team Foundation Server, process templates can use them to create team projects. The following procedure explains how to modify the process template XML to use a custom site template. To add a custom site template to a process template 1. On the Team Foundation Server, open a command prompt window.At the command prompt, change to the \Program Files\Common Files\Microsoft Shared\web server extensions\60\bin directory.Type stsadm -o enumtemplates and press Enter. The available site templates are listed. This information is needed to construct the appropriate process template XML. For example, if you added a site template named ExCustom you would see the following output: ExCustom - Language: Site Template: _GLOBAL_#1 - Template Id: 1 Note The template Id may be different depending on how many site templates are on the server. 2. In Visual Studio, on the Team menu, point to Team Foundation Server Settings, and then click Process Template Manager. 3. Download the process template you want to modify using the Process Template Manager. 4. In the process template, edit WSSTasks.xml.Find the site element, and change the template attribute to match the site template name you retrieved in step 2. The following XML shows an example of the site element for the ExCustom example template. <site template="_GLOBAL_#1" language="1033"/> 5. Upload the updated process template. You are now able to use the New Team Project wizard to create new team projects from the custom process template. The new team projects will use the custom site template for their project portal. Document Libraries After the project portal is created, you can specify that additional document libraries be created. Use the documentLibrary element to specify a document library. <documentLibraries> <documentLibrary name="" description=""/> </documentLibraries> The following list describes the attributes for the documentLibrary element. Name: Specifies the name of the document library that appears on the project portal. Description: Provides a description of the document library that appears on the project portal. The following example shows how to create a document library named Development that the development team can use to store documents. <documentLibrary name="Development" description=" Documents for the development team "/> Folders and Files After the project portal is created, you can specify additional folders to create. You can also specify files to copy such as template files. Use the folder element to create a new folder. <folders> <folder documentLibrary="" name=""/> </folders> The following list describes the attributes for the folder element. DocumentLibrary: Identifies which document library to create the folder in. Name: Specifies the name of the folder. The following example shows how to create a folder named Trip Reports in the Development document library where developers can store trip reports from conferences or customer visits. <folder documentLibrary="Development" name="Trip Reports"/> You can also copy files into document libraries and folders. The source files are located under the Windows SharePoint Services folder. You must specify a target on the project portal. <files> <file source="" documentLibrary="" target=”” queryId=”” /> </files> The following list describes the attributes for the file element. Source: A relative path to the local copy of the file. In general, the source path name always begins with Windows SharePoint Services. documentLibrary: The name of the document library into which the file will be copied. Target: A relative path to the target on the project portal where the file gets copied. queryId: Specifies the name of a work item query that is bound to the file. When the file is opened for the first time, it is populated with the results of running the query. This attribute is optional, and the specified query must exist in the workitems.xml file. The following example shows how to copy a template file named Project Checklist into the Templates folder. This example also specifies that when the file is first open, it should be populated with the results of the Project Checklist work item query. <file source="Windows SharePoint Services\Templates\Project Checklist.xls" documentLibrary="Project Management" target="Project Checklist.xls" queryId="Project Checklist" /> Note You could include folders and files as part of the site template, and you would not need to list them in the XML. However, there is a benefit to listing files in the XML. The New Team Project wizard will automatically bind Microsoft Project and Microsoft Excel files to the correct Team Foundation Server. This assists team members when they open the files because they will already connect to the correct Team Foundation Server. Process Guidance Process guidance files are installed by the Windows SharePoint Services plug-in. All of the process guidance files are located under the Windows SharePoint Services\Process Guidance folder, and a file element must be specified for each file to ensure it is copied to the project portal. Customization of process guidance is not covered in this document. For more information on customizing process guidance, see the MSF Process Guidance Customization Guide document in the extensibility kit. Note The process guidance source XML files are not designed to be edited by a regular XML editor. A Microsoft® Office InfoPath® 2003 form is provided for editing. For more information, see the MSF Process Guidance Customization Guide. Verification You can verify that the Windows SharePoint Services plug-in creates the project portal correctly by creating a new team project and following these steps: In Team Explorer, right-click the new team project and choose Show Project Portal. In the project portal, click Documents and Lists in the top navigation bar. Examine the Document Libraries section and ensure that all of your document libraries were created. Click each document library and ensure that any folders and files you specified appear correctly in their respective document libraries.

文档库和内容 Wss\WssTasks.xml: 指定文档库文件夹 / 默认的内容 ...
<site template="VSTS_MSFAgile" language="1033"/> <documentLibraries> <documentLibrary name="Project Management" description="Documents for the PM team"/> </documentLibraries> <folders> <folder documentLibrary=“..." name=“..." /> </folders> <files> <file source="Wss\Templates\Project Checklist.xls" documentLibrary="Project Management" target="Project Checklist.xls" /> </files> </site>

Version Control Plug-In
Microsoft.ProjectCreationWizard.VersionControl 默认定义: Version Control\VersionControl.xml 目的: 定义团队项目初始化时, 版本控制安全权限签入注释是否允许并发签出 Version Control Plug-in The Version Control plug-in defines a team project's initial version control security permissions, checkin notes, and whether or not exclusive check out is required. The plug-in name is Microsoft.ProjectCreationWizard.VersionControl. The Version Control XML file is named VersionControl.xml and is located in the Version Control folder in the process template folder hierarchy. You can change the XML file and folder name if necessary. In the XML file, specify 1 or more tasks and their dependencies. In general, you need only 1 task to configure version control settings. For an example of a task specifying version control settings, see the VersionControl.xml file in the MSF for Agile Software Development process template. Check-In Notes Checkin notes are provided by the developer when code is checked in to describe how, or if, the code changes are related to team processes. For example, a checkin note can indicate if the change was part of a security review, and include details about the changes in relation to the security review. Use the checkin_note element to define a checkin note. <checkin_note label="" required="" order=""/> The following list describes the attributes for the checkin_note element. Label: The label that describes the checkin note. The label is displayed to the user on the Pending Checkins dialog box when they perform a check in. Required: Specifies if the checkin note is required to have a value. If set to true, the checkin note must have a value. If set to false, a value is optional. Order: Specifies an order number to indicate what order to display the checkin notes. This attribute is optional. The following example shows how to customize the MSF for Agile Software Development checkin notes to provide an additional checkin note named "Documentation Impact" that is not required to have a value. <taskXml> <checkin_note label="Code Reviewer" required="false" order="1"/> <checkin_note label="Security Reviewer" required="false" order="2"/> <checkin_note label="Performance Reviewer" required="false" order="3"/> <checkin_note label="Documentation Impact" required="false"/> </taskXml> Exclusive Check Out You can control whether or not multiple people are allowed to check out a file at the same time. Use the exclusive_checkout element to specify the check out properties. <exclusive_checkout required=""/> If the required attribute is set to true, only 1 person can check out a file at a time. If required is set to false, multiple people can check out a file at the same time, and they must reconcile changes when they check in the file. The following example shows how to specify that exclusive check out is required. <exclusive_checkout required="true"/> Permissions Version control has a specific set of permissions that you can configure for a process template. Specifying permissions will define what actions security groups and individuals can perform on files under version control. Use the permission element to grant a permission for an identity. <permission allow="" identity=""/> The following list describes the attributes for the permission element. allow: Identifies the permissions being granted. The permissions are specified in comma delimited text. Identity: Specifies the Team Foundation Server security group, Windows group, or Windows identity to which this permission is applied. The following list describes the permissions you can specify for version control. Read: Can read the contents of a file or folder. PendChange: Can check out, add, delete, branch, merge, undelete, and perform other activities associated with a changeset. Checkin: Can check in changes. Label: Can apply a label to items. Lock: Can lock an item so that others cannot update it. ReviseOther: Can change the contents of someone else’s changeset comments and checkin notes. UnlockOther: Can remove someone else’s lock. UndoOther: Can undo someone else’s pending changes. LabelOther: Can modify someone else’s label. AdminProjectRights: Can configure security settings for version control. CheckinOther : Can check in as another user. This permission is required for conversion utilities. Note If a permission cannot be found for an identity, the permission will be searched for in any other groups the identity belongs to. If the permission cannot be found, the default action is to deny the permission. The following example shows how to grant permissions to allow the Contributor group to make modifications to files under version control. <permission allow="Read, PendChange, Checkin, Label, Lock" identity="[$$PROJECTNAME$$]\Contributors"/> Verification You can verify that version control settings for a process template are configured correctly by creating a new team project and following these steps: In Team Explorer, right-click the new team project and choose Team Project Settings, Source Control. In the Source Control Settings dialog box, select the Checkout Settings tab. Ensure that Enable multiple checkout is either selected or cleared depending on how you defined the exclusive_checkout element. Select the Checkin Notes tab. Ensure that each checkin note for the process appears and is appropriately marked as required or not required. From the Start menu, open the Visual Studio Command Prompt. In the command prompt window, type "tf workspace /new /computer:<client computer name> /s:<Team Foundation Server name>" and press enter. In the Create Workspace dialog box, enter a name for the new workspace and click OK. Type "tf permission /recursive" and press Enter. View the permission list for the folder for your team project and verify that your permissions are specified correctly. Note: When you create the team project, be sure to create a source code control folder in the New Team Project wizard.

Reports Plug-In Plug-In 名称: 默认定义: 目的:
Microsoft.ProjectCreationWizard.Reporting 默认定义: Reports\ReportsTasks.xml 目的: 定义团队项目的初始化报告指定报告的RDL文件指定报告的参数将数据源映射到报告 Reports Plug-in The Reports plug-in defines a team project's initial reports. The plug-in name is Microsoft.ProjectCreationWizard.Reporting. The Reports XML file is named ReportsTasks.xml and is located in the Reports folder in the process template folder hierarchy. You can change the XML file and folder name if necessary. In the XML file, specify 1 or more tasks and their dependencies. For an example of tasks specifying simple reports, see the ReportsTasks.xml file in the MSF for Agile Software Development process template. Reports Site For the reports to run correctly, you must create a reporting site. The reporting site will have a link to it on the project portal home page labeled Reports. To create the reporting site, use the site element as shown in the following example. <task id="Site" plugin="Microsoft.ProjectCreationWizard.Reporting" completionMessage="Project Reporting site created."> <dependencies/> <taskXml> <ReportingServices> <site /> </ReportingServices> </taskXml> </task> Folders You can create folders on the reporting site using the folder element. Use the path attribute to specify the relative path name of the new folder. The folder appears on the project site and under the Reports folder in Team Explorer. <folder path=""/> The following example creates a Public folder on the reporting site. <task id="Populate Reports" completionMessage="Project site created."> <dependencies> <dependency taskId="Site"/> </dependencies> <folders> <folder path="Public"/> </folders> Reports Reports are defined by .rdl files. To add reports to the reporting site, copy the report .rdl files into a folder under the Reports folder in the process template. Then use the report element to describe the necessary properties and data sources for the report. <report name="" filename="" folder="" cacheExpiration ="30"> The following list describes the attributes for the report element. name : The name of the report to display on the reporting site and in Team Explorer. filename : A relative path under the local Reports folder from where to get the .rdl report file. folder : A relative path name of where to add the report on the reporting site. cacheExpiration : Sets the default number of minutes the report is cached. You can specify values for parameters in a report. This is often used to map the Project parameter to the current team project. Most reports will not run correctly without a reference to the current team project. To map the Project parameter to the current team project, specify the value as $$PROJECTNAME$$. <parameters> <parameter name="" value=""/> </parameters> The following list describes the attributes for the property element. name : The name of the parameter in the report to bind. value : The value to which to bind the parameter. You must map each data source name in each report to a live Team Foundation Server data source. Use the reference element to specify a data source. <datasources> <reference name="" dsname=""/> </datasources> The following table describes the attributes for the reference element. name : The name of the data source in the report. dsname : The name of the Team Foundation Server data source. Typically this value is either TfsReportDS, or TfsOlapReportDS. The following example shows how to add a Work Items report. The Project parameter will be bound to the current team project, and the report will be bound to the TfsReportDS data source. <report name="Work Items" filename="Reports\Work Items.rdl" <parameter name="Project" value="$$PROJECTNAME$$"/> <reference name="/TfsOlapReportDS" dsname="TfsOlapReportDS"/> <reference name="/TfsReportDS" dsname="TfsReportDS"/> </report> Verification You can verify that reports are created correctly by creating a new team project and following these steps: In Team Explorer, expand the team project Reports folder. Ensure that all of the reports are listed correctly. If possible, run each report by double-clicking it. Note: Some reports may not run if they require data that is not yet available.

Groups and Permissions Plug-In
Microsoft.ProjectCreationWizard.Groups 默认定义: Groups and Permissions\GroupsandPermissions.xml 目的: 定义团队项目初始化时安全组权限 Groups and Permissions Plug-in The Groups and Permissions plug-in defines a team project's initial security groups and their permissions. The plug-in name is Microsoft.ProjectCreationWizard.Groups. The Groups and Permissions XML file is named GroupsandPermissions.xml and is located in the Groups and Permissions folder in the process template folder hierarchy. You can change the XML file and folder name if necessary. In the XML file, specify 1 or more tasks and their dependencies. In general, you specify one task per security group to create for your process. For an example of a task specifying a simple security group and permissions, see the MSF for Agile Software Development process template. Groups Use the group element to specify a new Team Foundation Server security group. <group name="" description=""></group> The following list describes the attributes for the group element. name : Specifies the name of the group being created. description : Provides a description of the group to help users understand the purpose of the group The following example shows how to create a group named Reader. <task id="GroupCreation1" name="Create Groups and Permissions" plugin="Microsoft.ProjectCreationWizard.Groups" completionMessage="Groups and Permissions created."> <taskXml> <groups> <group name="Readers" description="A group for those with read access across the project"> <permissions>  </permissions> </group> </groups> </taskXml> </task> Permissions For each group that you specify, you must also specify permissions. Use the permission element for this purpose. <permission name="" class="" allow=""/> The following list describes the attributes for the permission element. name : Identifies which permission is being applied. class : Identifies the class, or area, where the permission is being applied. allow : A true or false value indicating if the permission is being allowed or denied. The following table describes each class and name combination you can specify as a permission. NAMESPACEGENERIC_READ : Can view information at Team Foundation Sever level. NAMESPACEGENERIC_WRITE : Can change settings on Team Foundation Server. NAMESPACEMANAGE_EVERYONE_GROUP : Can add or remove members to the TFS Everyone global group. NAMESPACECREATE_PROJECTS : Can create new team projects. NAMESPACEADMINISTER_WAREHOUSE : Can administer the data warehouse. NAMESPACECHECK_IN : Can check in files at Team Foundation Server level. PROJECTGENERIC_READ : Can view information for this team project. PROJECTGENERIC_WRITE : Can change settings on this team project. PROJECTDELETE : Can delete this project. PROJECTCHECK_IN : Can check in files. PROJECTPUBLISH_TEST_RESULTS : Can publish test results. PROJECTDELETE_TEST_RESULTS : Can delete test results. PROJECTADMINISTER_BUILD: Can administer a build. PROJECTSTART_BUILD: Can start or resume a build. PROJECTEDIT_BUILD_STATUS : Can edit the build status. PROJECTUPDATE_BUILD : Can write to the build operational store. CSS_NODEGENERIC_READ : Can view CSS nodes. CSS_NODEGENERIC_WRITE : Can change CSS nodes. CSS_NODECREATE_CHILDREN : Can create and order child nodes under a node. CSS_NODEDELETE : Can delete CSS nodes. CSS_NODEWORK_ITEM_READ : Can view work items in CSS nodes. CSS_NODEWORK_ITEM_WRITE : Can edit work items in CSS nodes. EVENT_SUBSCRIPTIONGENERIC_READ : Can view alerts. EVENT_SUBSCRIPTIONGENERIC_WRITE : Can change alert settings. EVENT_SUBSCRIPTIONUNSUBSCRIBE : Can unsubscribe from alerts. The following example shows how to grant permissions to the Reader security group such that readers can view team project information, but not modify it. <group name="Readers" description="A group for those with read access across the project"> <permission name="GENERIC_READ" class="PROJECT" allow="true" /> <permission name="GENERIC_READ" class="CSS_NODE" allow="true" /> <permission name="WORK_ITEM_READ" class="CSS_NODE" allow="true" /> Verification You can verify that security groups and permissions are created correctly by creating a new team project and following these steps: In Team Explorer, right-click the new team project, point to Team Project Settings, and then click Security. In the Project Security dialog box, you should see the names of your security groups listed. Ensure all security groups are correct. Select a security group. You should see the permissions for that security group listed at the bottom of the Project Security dialog box. Ensure that the permissions are correct.

扩展项目生成向导利用.NET生成自定义Plug-in 实现 IProjectCreationPlugin 接口
Project Creation Wizard Page (WizardForm) 可选在过程模板XML中增加Plug-in 创建团队项目的计算机必须安装Plug-in <TO DO>

工作项客户化默认的工作项定义场景任务质量缺陷风险需求任务缺陷风险变更请求问题评审工作项客户化方法

工作项类型客户化

Work Item Type Definitions
XML文件包括的Work Item type definition: Work Item Type declaration Global List definitions (可选) Fields Workflow Form

导入/导出工作项的工具 Team Foundation Server的命令行工具 WITEXPORT WITIMPORT WITFIELDS
GLEXPORT GLIMPORT WITIMPORT Use the witimport command to validate and import a work item type from an XML file to a team project on a Team Foundation Server. If you try to import a work item type that already exists in the specified team project, a warning prompt asks if you want to overwrite the existing work item type. You can validate a work item type without importing it by using the /v option. The witimport command-line utility is located in <drive >\Program Files\Visual Studio8\Common7\IDE. witimport /f filename /t tfs /p teamproject [/v] [/e encodingname] WITEXPORT Use the witexport command to export an XML definition for a work item type from a Team Foundation Server. You can also use this command to print an XML definition to the display. The witexport command-line utility is located in <drive >\Program Files\Visual Studio8\Common7\IDE. witexport [/f filename] /t tfs /p teamproject /n witname [/exportgloballists] [/e encodingname] WITFIELDS Use the witfields command to administer work item type fields for Team Foundation Server. Note Team Project Administrators may not be able to administer all the fields for Team Foundation Server. The witfields command-line utility is located in <drive >\Program Files\Visual Studio8\Common7\IDE. witfields view /s:tfs [refname | /unused]witfields rename /s:tfs refname newnamewitfields report /s:tfs refname {dimension | detail | measure | disable}[:sum | :count | :distinctcount | :avg | :min | :max]witfields delete /s:tfs refnamewitfields rebuildcache /s:tfswitfields help GLEXPORT Use the glexport command to export an XML definition for global lists from a Team Foundation Server. You can also use this command to print an XML definition to the display. The glexport command-line utility is located in <drive >\Program Files\Visual Studio8\Common7\IDE. glexport [/f filename] /t tfs [/e encodingname] GLIIMPORT Use the glimport command to validate and import global lists from an XML file to a team project on Team Foundation Server. If you try to import a global list that already exists in the specified team project, a warning prompt asks if you want to overwrite the existing global list. If a global list does not already exist, a new one will be created. The glimport command-line utility is located in <drive >\Program Files\Visual Studio8\Common7\IDE. glimport /f filename /t tfs [/e encodingname]

工作项类型规则 When / When Not Allowed value lists Dependent pick lists
Default values Required Fields <REQUIRED /> <READONLY /> <EMPTY /> <FROZEN/> <CANNOTLOSEVALUE/> <NOTSAMEAS field=’Foo’ /> <VALIDUSER /> <VALIDDATE mustbe=’after now’/> <ALLOWEXISTINGVALUE/> <MATCH pattern=’<pattern>’/> Defining Field Constraints Field rules define the behaviors and constraints on fields and are additional elements that are listed inside <FIELD></FIELD> blocks. For example, if a field is required, the XML would look like this: <FIELD refname="System.Priority" name="Priority" type="String"> <HELPTTEXT>Enter the business priority of the bug</HELPTEXT> <REQUIRED /> </FIELD> This field is required to be non-empty. All field types may be marked as required. <READONLY /> The field cannot be modified. <EMPTY /> The field value will be cleared on commit and the user will not be allowed to enter any value. Used primarily during state transitions. <FROZEN/> Once a field has a value after a commit, it can no longer be modified. It can however be cleared using an <EMPTY/> rule or manually by a user and filled in again later. Used primarily during state transitions. <CANNOTLOSEVALUE/> Once a field has a value it cannot be cleared or made empty. <NOTSAMEAS field="Example" /> The field value cannot have the same value as the value in the field "Example." For example, two fields cannot be empty at the same time or the "code reviewer" field value cannot be the same as the "assigned to" field value. This should be used for fields of like type. It is not supported for PlainText or HTML fields. <VALIDUSER /> The field value must be a valid user who is a member of TFS Everyone. Note: If the <REQUIRED/> rule is not specified, this field will accept an empty value. Used for String field types. Note: Work item fields do not distinguish between user identities in different domains. Thus, "Example1\jaepak" and "Example2\jaepak" are treated as the same user when entered into a field with the <VALIDUSER /> rule. However, user identities are distinguished by domain elsewhere in Team Foundation. <VALIDDATE mustbe="after now"/> Validate a date field. The Mustbe value can be either "after now" or "not after now." "after now" is after the current time. "not after now" requires the field value to be the current time or before. Used for DateTime field types. All dates are evaluated on the server and based on the server clock. <ALLOWEXISTINGVALUE/> Allows a field to retain an existing value, even if that value is no longer allowed. The alternative and default behavior is to force the user at edit time to conform to the latest allowed values for that field. This element will only have a modifying effect on the elements in the same block. This element cannot accept "for" or "not" attributes. <MATCH pattern="<pattern>"/> Enforces basic pattern matching for strings only. <pattern> should be replaced with the match pattern. Valid values are "A," "N," "X." All other values are taken as literals. "A" represents an alphabetical character. "N" represents a numeric character. "X" represents any alphanumeric character. This is only supported for string type fields.

工作流状态与转换工作项的状态: 工作项状态的转换: State Name Field constraints for the state
Source and destination state Linkage to VSTS automatic state transition (actions) The valid (and default) reasons for the transition The field changes occurring as a result of the transition Defines the security for transitions Workflow Overview The workflow section of the WITD describes the valid states, legal transitions, and legal reasons for the transitions. Reasons identify why the user is changing from one state to another. The workflow section looks like this: <WORKFLOW> <STATES> <STATE value="Active" /> <STATE value="Complete" /> </STATES> <TRANSITIONS> <TRANSITION from="" to="Active"> <REASONS> <REASON value="New"> </TRANSITION> <TRANSITION from="Active" to="Complete"> <REASON value="Deferred"/> <REASON value="No Plans to Fix"/> </REASONS> </TRANSITIONS> </WORKFLOW> One and only one transition must be defined from nothing (described as "") to a named state. This identifies the initial state for a new work item. Every transition must define at least one reason. The smallest workflow for a work item must contain one state, one transition, and one default reason. Below is the smallest workflow you can define. <STATE value=”EXISTS” /> <TRANSITION from=”” to=”EXISTS” /> <REASON value=”New”> Note: State names and reasons are case insensitive. Transition Security All legal transitions between two states must be specified. If no transition is specified, then the default is to not allow this transition to be performed. In addition, two attributes, "for" and "not," can be optionally used in the transition element of workflow to refine who is allowed to perform a transition. Denies take precedent over allows. If neither of these attributes are specified, then anyone is allowed to make this transition (specifically anyone who can modify the work item). Here is an example of a rule which restricts transitions to complete to all project testers, except for new testers who have just joined the team. <TRANSITION from="Resolved" to="Complete" for="AllTesters" not="NewTesters"> Note: Multiple groups are only supported by creating a parent group and using the parent group. Scoping Field Rules by State, Transition, or Reason As we have defined them so far, field rules determine work item type behavior regardless of the state of the work item. For example, a field that is required for a bug that is new and active is still required up to the time that the bug is closed. Field rules can also be scoped to certain states, transitions, or even reasons. The complete set of rules that apply to any given field is additive from four subsets: work item type-specific, state-specific, transition-specific, and reason-specific. Work item type-wide rules apply regardless of where a work item is in its state model. For example, a <REQUIRED/> rule makes the following check: “MyField Value” != NULL State-specific rules are scoped to a work item instance when it is in a certain state. So the check is: State field value == “MyState” && “MyField Value” != NULL Transition-specific rules are scoped to a work item that is undergoing a certain transition. The check for these rules is more complicated: State field value == “ToState” && “Previous State Before Edit/New” == “FromState” && “MyField Value” != NULL Reason-specific rules are scoped to a particular reason on a particular transition. The check for these is the most complicated: Reason field == “MyReason” && “Previous State Before Edit/New” == “FromState” && “MyField Value” != NULL Scoped field rules are done by using <FIELDS> and <FIELD> elements within the <STATE>, <TRANSITION>, and <REASON> elements. Note: When listing fields in the workflow, you should only specify the field reference name. The example below defines the following rule: when a bug is in the active state, do not allow the customer severity field to be modified. <STATE name=”Active”> <FIELDS> <FIELD refname="MyCorp.Severity" /> <READONLY /> </FIELD> </FIELDS> </STATE> State Transition Actions (Automating State Transitions) Customers and partners may want to automatically transition work items from state to state based on events that happen elsewhere in team system or events that occur outside of team system itself (for example, from a call tracking tool). The work item type model and object model are extended to support automatic transitioning of work items by other systems (including Microsoft’s) The following extensions illustrate some examples of this. A tool is preset to automatically transition a work item to "resolved" after the user checks in a change. However, as an integration provider you do not know what state the work item type author has declared as "resolved." It could be Resolved, Closed, Completed, Ready For Test, Include In Build, and so on. One option would be to require all work item type authors to include a state explicitly named "Resolved." However, this is too restrictive and very poor from an international perspective as it does not allow localization of states. Instead, integrators declare an action (for instance, "check-in," "complete") in their system which will induce an automatic transition for work items. The work item type author then declares this action on the appropriate transition. Identifying the proper state transition In this example, the Team Foundation version control system needs to support automatic transitions of work items at check-in time. An "example1.vsts.actions.checkin" action is defined. A work item type author can define a "Defect" work item type that has a state called "Working" for when a developer is making changes and another state called "Ready To Build" which identifies when the defect has been declared ready for the nightly build by the developer. The author can automatically transition the work item from state "Working" to "Ready To Build" during a check-in operation by declaring the following: <TRANSITION from="Working" to="Ready To Build"> <ACTIONS> <ACTION value="microsoft.vsts.actions.checkin"/> </ACTIONS> Automating the transition For integrators, defining the action is just the first step. When the tool is performing the action, they must define the transition. For example, when the Team Foundation version control system is performing the check-in operation, it needs to perform the auto-transition. The version control system can query the work item tracking system through an object model call to find out the correct "To" state into which it should transition the associated work item: nextState = workiteminstance.GetNextState("example1.vsts.actions.checkin"); If the current state of the work item instance has an action entry for the specified action, then it returns the "To" state. If not, the return value is Null. Transition actions are a helper capability for partners and integrators who want to perform auto-transitions. Once an integration gets the next state, what they do from there is up to them. There is no record kept of what transition action caused a particular state transition to occur; only the normal Reason for the transition is recorded. If this kind of tracking is desired, it is recommended that the work item type author identifies a specific value as a legal reason and the automation sets this value into the Reason field during the transition. Transition Action Details Actions are optional. Integrations should handle Null return values gracefully. That is: a) do not fail and b) leave some trace or log that the integration did not auto-transition because it required action "xyz" and it was not found. For each work item type, actions must be unique for "From State / Action" pairs. That is, work item type authors cannot specify multiple "To" states for the same action. However, multiple actions on the same transition are supported to allow for multiple auto-transition integrations. For example: <ACTION value="Microsoft.VSTS.Actions.Checkin"/> <ACTION value="ADatum.Actions.Complete"/> Action names are not localizable. Action names should follow the same reference namespace convention as field reference names. This avoids action name conflicts between vendors and customers. However, this will not be enforced by the tool. Microsoft Visual Studio Team System will use "Microsoft.VSTS.Actions.<your action>". Auto-Transition Error Checking and Work Item Type Author Advisement There are two types of auto-transitions integrators can attempt. The first is auto-transitions which occur due to some user action. The second is an auto-transition happening as a result of an unattended automation (for example, a nightly build). In the first case, you can assume a user will be present to react to any rule-related issues that might come up, and should support the fact that a work item type author can add a new required field that your integration does not know about. To do this, after doing the auto-transition you need to check the work item type for rule violations. If any are found, pop-up the form for the user to resolve. For the second case, you cannot deal with any of these issues because there is no user present to resolve them. In this case the integration should fail gracefully, leaving some indication in an error log that the auto-transition was attempted and why it failed. The ideal case, is when auto-transitions occur without user intervention. The work item type author can do a few things to support this. First, always specify a default reason. In this way, neither the integrator nor the end user needs to specify the reason for the transition. Secondly, ensure that there are default values for all required fields for the transition. In this way, all the appropriate information is filled in automatically.

表单定义定义在 Team Explorer 中的工作项界面 Tabs Groups Controls (everywhere!)
TabGroup Columns Controls and their mapping to field TabGroup Tabs Groups Controls (everywhere!) Defining the Form Content and placement of user interface elements is controlled by the <FORM> section of the WITD. Each work item type must have only one. The whole form is described, including all tabs, fields, and groups. The objective is that from one form definition, you can properly layout the work item form in Visual Studio, in the hosted windows form control, and in Windows® SharePoint® Services Web parts. Design it once and use it anywhere is the philosophy. At the top level, there are three elements to the <FORM> section of a WITD; <Layout>, <Group>, and <Column> <LAYOUT> This parent element contains all the layout information for the work item type form. Child elements contained within the Layout element place groups, columns, and controls on the form. <GROUP> Child elements contained within the Group element are contained in the same group on the form. A group is demarcated by a border and an optional label. Adjacent groups stack vertically. <COLUMN> A column element keeps all of its child elements in the same column and splits a form horizontally. Columns must appear in a <GROUP> element. <GROUP> elements within <COLUMN>s can be used to create nested groupings. By default, columns split a <GROUP> evenly. An optional PercentWidth attribute can be used to change the column width. The XML example below defines a form with two rows of groups and two columns in each group. <FORM> <COLUMN PercentWidth="70"> ... </COLUMN> <COLUMN PercentWidth="30"> </GROUP> <GROUP Label="2nd Group"> </LAYOUT> </FORM> Controls Controls are used to render fields or other information on the form. Each <CONTROL> element has a Type attribute and an optional Label. The Type attribute is used to specify several control types that are discussed below: FieldControl WorkItemClassificationControl WorkItemLogControl LinksControl AttachmentsControl The Label attribute specifies the text to display next to the control. The related LabelPosition attribute specifies where the label appears relative to the control. Control Types This control is used to display a field on a form. The field control must refer to a field by reference name. <Control Type="FieldControl" FieldName="System.Title" Label="Title" LabelPosition="Left" /> This control displays the Area Path and Iteration Path fields in a tree. The tree shows hierarchical nodes that can be expanded and collapsed. <Control Type=" WorkItemClassificationControl" FieldName="System.AreaPath" Label="Area" LabelPosition="Left" /> This control renders the work item's history and conversation fields. Details about historical revisions to the work item can be expanded and collapsed using this control. <Control Type="WorkItemLogControl" FieldName="System.History" Label="Detailed Description and History" LabelPosition="Top" Dock="Fill" /> This control displays links from this work item to other work items. Users can open, edit, add, and remove links using this control. <Control Type="LinksControl" /> This control displays the file attachments for the work item. Users can open, add, and remove file attachments using this control. <Control Type="AttachmentsControl" /> Columns

工作项客户化

Team Foundation Server 可扩展性

Team Foundation Server 可扩展性
Visual Studio Your .NET App Your VSIP Package Your PCW plug in Your TE Node Team Foundation OM Work Item OM Version Control OM Registration Svc Proxy Linking Service Proxy Policy Framework Eventing Service Proxy Security Service Proxy Client Common Controls Classification Svc Proxy Application Tier Version Control Service Warehouse Adapter Changeset / Source File Work Item Tracking Svc Warehouse Adapter Work Item Team Build Service Warehouse Adapter Build Your Service Warehouse Adapter Your Artifacts TO DO – Add notes to this Registration Service Linking Service Eventing Service Security Service Classification Service TF Data TF Facts Your Facts TF Facts Your Data Data Tier Reporting Warehouse

TeamPlain Web Access Eclipse Plugin VS2003 Plugin

TeamPrise Stand Alone User Interface Eclipse Plugin

Eg. Work Item Spawning Take Order: Take Order: Scenario Take Order
Task Take Order: Write Spec Listen for WorkItemChanged event for Completed Task Use work item object model to update parent Scenario Task Take Order: UI Design Scenario Take Order Task Take Order: Test Plan Work Item Spawning Example Here is an extensibility solution which is responsible for spawing new work items based on the state of others. In this example a “listener” application has been created that watches for events on the Team Foundation Server, in this case the WorkItemChanged event. When the Listener receives and asynchronous notification that a WorkItem has changed, the Listener application can then use the Work Item Object model to retrieve the details of Listen for WorkItemChanged event for new Scenario Use work item object model to create new Tasks Use work item object model to link new Tasks to original Scenario Task Take Order: Dev Schedule

Team Foundation Server Object Model
Team Server Object Model The Team Foundation Server object model is the public interface to the Team Foundation Server. It communicates with Web services on the application tier which in turn communicates with the SQL database on the data tier. Consumers such as the Team Foundation Client or integrators can sit on top of the Team Foundation Server object model to interact with the Server. The root node of the object model is encapsulated by the TeamFoundationServer managed class. This class contains basic properties of the server and APIs for working with various components of the server such as source code control and work item tracking. Connecting to a TFS To connect to a TFS, users must construct a TeamFoundationServer object. The TeamFoundationServerFactory should be used to get create an instance of a TeamFoundationServer object. When a TeamFoundationServer object is created by the factory, an instance of it will be cached so subsequent calls to the factory will return the same instance. It is important that all Team Foundation services share the same Team Foundation Sever instance to avoid multiple prompts for credentials. The TeamFoundationServerFactory method signatures match those of the TeamFoundationServer constructors. One constructor takes only a server name and defaults to the caller’s Windows credentials. Additional constructors are available for specifying non-default credentials. Non-default credentials are discussed further in the next section. public static class TeamFoundationServerFactory { public static TeamFoundationServer GetServer(string name) public static TeamFoundationServer GetServer(string name, ICredentials credentials) public static TeamFoundationServer GetServer(string name, ICredentialsProvider credentialsProvider) } Note that the name of the Team Foundation Server can be specified as either a URL or friendly name. Authentication The ICredentialsProvider interface is used for authenticating users other than the currently running user. The UICredentialsProvider class implements this interface. The examples below illustrate use of non-default credentials. Handling credentials from a console application // Parses the /login option or sets default credentials, among other things. Command command = CreateCommand(args); ICredentialsProvider provider = new UICredentialsProvider(); TeamFoundationServer m_tfs = TeamFoundationServerFactory.GetServer(m_server, provider); while (true) { try { // A Command requests by URL a TFS object from CommandLine object once it // determines the URL. // CommandLine object has a method to get cached credentials from the // credentials provider based on user name and URL. command.Run(); break; } catch (UnauthorizedException) { // Now prompt user, etc. If it succeeds, we try the command again. // Otherwise, Authenticate() // will throw an Unauthorized exception and break out of this loop. m_tfs.Authenticate(); } Handling credentials on a server application // Use default credentials (e.g., ASNET user), retrieve from registry, // retrieve from DPAPI cache, etc. TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(m_server); try { // Find out up front whether we can even start. tfs.Authenticate(); // Make tfs calls // If any subsequent call fails with the unauthorized exception, the whole // thing ends. For example, the current user's account password expires. } catch (UnauthorizedException) // Somehow record the problem. For example, write event to event log, send // , update status Web page, etc. Handling credentials for a Windows application // Start UI, bring up application. // At some point in the app, make the first contact with the server // by authenticating logged on user or whatever is specified in VS // options dialog. TeamFoundationServer tfs = TeamFoundationServerFactory.GetServer(m_server, provider); // Make sure we can go. // Now try to authenticate. If unsuccessful, use tfsUICredProvider to // request credentials. tfs.Authenticate(); // User can't or won't authenticate. Shut down the app. // Do other UI stuff. At any time, an unauthorized exception could occur // due to password expiration, changing users by dropping and reconnecting // to the VPN, etc. The UI app writer will need to decide whether to handle // that, and if so, call tfs.Authenticate() when catching the exception. TeamFoundationServerFactory GetServer The TeamFoundationServerFactory should be used to get an instance of a TeamFoundationServer object. When a TeamFoundationServer object is created by the factory, an instance of it will be cached so subsequent calls to the factory will return the same instance. It is important that all Team Foundation services share the same Team Foundation Sever instance to avoid multiple prompts for credentials. Logic of getting a TeamFoundationServer object: If a TeamFoundationServer object with the specified name exists in the cache, it is returned. If not, one is created with the default credentials for the current user and no credential provider. The created TeamFoundationServer object is placed in the cache and associated with the Uri resolved for the name. Each of the TeamFoundationServerFactory method signatures match the method signatures of the TeamFoundationServer constructors. Getting a Team Foundation Server: Syntax

Work Item Object Model The work item object model is the public interface to the work item tracking components of Microsoft® Visual Studio 2005® Team System. It communicates with the work item tracking Web service on the application tier which communicates with the SQL Server™ database on the data tier. Consumers such as the Team Explorer or integrators can sit on top of the work item object model to interact with the work item tracking system. The root node of the work item object model is encapsulated by the WorkItemStore managed class and is one of several APIs exposed by a Team Foundation Server, encapsulated by a TeamFoundationServer class. For every TeamFoundationServer, there is exactly one WorkItemStore, which covers all the work items, fields, and stored queries defined for that Team Foundation Server. At a high level, the WorkItemStore allows users to get instances of work items, which contain information such as field values, links, and attachments. It also allows users to get information about the context of work items, such as team projects and work item types. Scenarios Here are common scenarios involving the Work item object model. Visual Studio 2005 SDK The VSIP client displays queries, results, and individual work items. It interacts with the Team Foundation work item tracking via the Work item object model. Visual Studio 2005 SDK does not have to interact with any other APIs, such as the Web service. It has one consistent API to work from and does not have to duplicate any logic for handling work items. Customers Jose, an A. Datum developer, just deployed Team Foundation at his company. He is interested in integrating work item tracking into his company's in-house development environment. He deploys a Team Foundation Server. From this object, he sees all the available services for the Team Foundation Server API, including the work item object model. He browses the work item object model to get a feel for how it works. After investigating, Jose decides to add a user interface to their development environment that leverages the Work item object model to show stored queries, run queries, and open individual work items. Tool Smiths Jill, an independent software vendor architect, sees an opportunity to build a tool that integrates Team Foundation work item tracking with Microsoft® Office Outlook® The tool allows users to see and manipulate their assigned work items from Outlook's task list. Her team codes against the work item object model and Outlook's API to query for a user's work items and add those work items to the task list. When users modify their tasks in Outlook, the tool applies the changes to the work items on the Team Foundation Server. Using the Object Model The subsequent subsections discuss the basics of using the work item object model. Getting Work Items The most basic function of the WorkItemStore is getting work items. A work item is uniquely identified by its ID (a positive integer) and Artifact URI (see the Team Foundation Linking Service document for more information about artifacts). The WorkItemStore exposes methods for getting any existing work item using either of these unique identifiers. public WorkItem GetWorkItem(int id) public WorkItem GetWorkItem(Uri uri) Additionally, every revision of a work item is stored so that users can also get work items as of a specific date/time or revision index. public WorkItem GetWorkItem(int id, DateTime at) public WorkItem GetWorkItem(int id, int revision) public WorkItem GetWorkItem(Uri uri, DateTime at) public WorkItem GetWorkItem(Uri uri, int revision) Manipulating Work Items After getting an existing WorkItem or creating a new WorkItem using the constructors below, you can read values from the work item and make edits. public WorkItem(WorkItemStore store, WorkItemType type) The major components of a work item are as follows. Store – Every work item belongs to a WorkItemStore. Project – Every work item belongs to a team project on the Team Foundation Server. Type – Every work item is an instance of a specific work item type. The work item type defines the fields, rules, and workflow for the work item. Work item types are scoped to team projects. Revision – The revision count for the work item. Revisions – The collection of all revisions of the work item. Do not get this confused with the System.History field which is a text field used to track the conversation thread for a work item. Fields – The collection of fields defined by the work item type. The value for each Field in the collection can be viewed and edited. Links – A collection of outbound links. Work items can link to each other, other artifacts, or URL/UNC paths. Attachments – A collection of file attachments that are stored with a work item on the server. The Fields, Links, and Attachments collections of a WorkItem can be viewed and edited. Once any edits are made to these parts of a WorkItem, the work item is marked as dirty via the IsDirty property. Changes to a work item are committed to the server via Save() method. Unless a work item is saved, all changes to it will be lost. When saving a work item, rules defined for the work item type will be evaluated. Violations will throw exceptions upon saving. If there are no violations, the work item is successfully saved, its revision is incremented, and its history updated with the latest changes. Note that an IsValid() method can be used to evaluate whether a work item's fields pass all rules before attempting to save the work item. Each time a work item is committed, a new revision is created for that work item. The latest revision of a work item reflects its current state, while previous revisions reflect the state of the work item at different points in its history. Different revisions of a work item are akin to different versions of source code on a server. In this model of work item revisioning, the System.History field requires special handling. This field behaves like a discussion thread where each reply to the thread is stored in a separate revision of the work item. In the work item form, the aggregated values of all revisions of the history field is shown. When editing the history field programmatically, the caller can append a new entry to the history thread by setting the fields value in the current revision to the desired text. Because previous entries in the history thread are associated with previous revisions, the latest revision of a work item can have an empty History field value even if the history thread shows text on the work item form. A good example of reading and writing to the history field is provided in the samples.

Work Items Objects Work Item Context
A work item has a lot of context associated with it such as the following. Project – the team project to which the work item belongs Nodes – nodes used to classify the work item in hierarchies; Type – every work item must conform to a schema or type that dictates its fields, form, and workflow. Fields – every work item has a number of fields that can store various values At the top is the WorkItemStore, which holds all work items on a Team Foundation Server. The WorkItemStore contains a ProjectCollection and a FieldDefinitionCollection. The ProjectCollection holds all the team projects that are available on the server. Each Project defines a collection of Nodes and a collection of work item types. The NodeCollection represents the classification hierarchies for the project while the WorkItemTypeCollection represents all of the WorkItemTypes scoped to the project. Work item types refer to fields defined for the Team Foundation Server. These are captured by the FieldDefinitionCollection. Every work item type references a subset of the FieldDefinitions available for Team Foundation Server. Each FieldDefinition defines the field name, type, and other field attributes. WorkItems pull these pieces of metadata together. A work item belongs to particular Nodes which reflect their classification. The team project to which a work item belongs can be inferred by its Nodes and their parent Project. A work item also has a WorkItemType that encapsulates the work item's schema. Lastly, a work item has a collection of fields and associated values. This is stored in a FieldCollection. This collection contains various Fields, which behave according to their FieldDefinitions. WorkItemStore This class encapsulates the store that contains all work items for a particular Team Foundation Server. A store is scoped at the server level. Members are listed below. WorkItemCollection This class encapsulates a collection of work items. This class implements ReadOnlyList, a read-only collection. Objects of this class can only be returned from a query of the WorkItemStore so all constructors are private or internal. WorkItem This class encapsulates a work item instance. Query This class encapsulates a query against the work item store. Queries are scoped to a WorkItemStore and are described in the WIQL language. Members are listed below. All Properties are read-only and inferred from the WIQL used to construct the query. Node This read-only class encapsulates nodes used for classifying work items by Area and Iteration. These Nodes are designed to mirror CSS nodes. The work item store replicates CSS node information for performance reasons. Each Node tracks its parent Node and child Nodes. This class implements IEnumerable to enumerate the child nodes. Project This is a read-only class that inherits from Node. It encapsulates a node representing a team project within the work item store. Every work item must belong to a team project or Project node. WorkItemTypeCollection This collection class is designed to hold work item types. It can be used to import new work item types into the project to which this collection belongs WorkItemType This is a sealed class that represents a work item type. FieldDefinitionCollection This sealed class is used to hold field definitions. FieldDefinition This class is used to hold field definitions. Field This sealed class is used to hold field-value pairs for work items. The behavior of Field classes depends on the state of the parent work item and other fields of that work item. CoreFieldReferenceNames This class holds the reference names for all the CoreField's. Each core field friendly name is a property of this class whose static value is corresponding reference name string. For example, the value of CoreFieldReferenceNames.Id is "System.Id." Link This abstract class is the base class for all other links (Hyperlink, RelatedLink, and ExternalLink). In general, there is no validation of the link target when instantiating Link objects (including for sub-classes). The caller should validate the link target before creating a Link object that references the target. Enumerations FieldType Enumerates all field definition types. Possible values include String, Integer, DateTime, etc. FieldStatus Enumerates the status of a Field. The status depends on the validity of the field's value. Possible values include Valid, InvalidEmpty, InvalidNotEmpty, InvalidListValue, etc. CoreField Enumerates common work item core fields. The associated values of the enumeration list are unique int IDs that are the same for any Team Foundation Server. WorkItemStoreState Enumerates the states that a WorkItemStore can be in. Includes "Connected" and "Disconnected.“

Event Service Web services-based pub/sub Tools register event types
Send SOAP messages to interested subscriber services Send messages to interested people Event Delivery is not guaranteed Event Service Overview Events requiring user notification occur in several Microsoft® Visual Studio 2005® Team System applications. Events are also used to integrate loosely coupled services. Therefore, Team System includes a flexible, extensible mechanism for subscription and notification. The most common user notification mechanism is . The most common service notification mechanism is Web services. The Team Foundation Notification Service is a reliable, asynchronous publish/subscribe event notification system supporting the distributed Visual Studio Team System environment. The notification service enables a tool or service to register event types. Users and other services can subscribe to those events. When the source tool raises an event, the event is matched against subscriptions and notifications are generated. Notification is accomplished in one of these ways: A subscriber can specify that the notification is to be made to an end-user through . A subscriber can identify a Web service to invoke. Eventing Service Design When a Team Foundation-enabled application needs to raise an event within the Team Foundation Eventing Service, it can call directly into the Eventing Web service API, or it can use the EventService service that is part of the Team Foundation Core Services SDK assembly. After the API returns successfully, the event is delivered to its subscribers. The calling application does not wait while subscriptions are matched and notifications are delivered. The diagram depicted in the slide illustrate the flow of Eventing Service and the structure of the available event classes. Delivery methods Team Foundation Eventing Service supports the following delivery methods: End-User Delivery: This delivery method is used for end-user subscriber scenarios. Team Foundation includes a set of templates to support the relevant event types offered by Visual Studio Team System tools. Partner tools can add new templates as part of their registration into Team Foundation. Once the content is generated, text is sent using SMTP to the address registered in the subscription. Web Service Listener: This delivery method is used principally for Visual Studio Team System service component subscriber scenarios. A Visual Studio Team System application that is interested in receiving notifications implements a Listener Web Service interface. Team Foundation calls the interface to pass on the notification object as an XML document. Summary of Integration Points To generate events: At install time, provide an event schema for each event type to Team Foundation. At run time, to raise an event, call the FireAsyncEvent method of the Team Foundation Eventing Web Services. For events targeted at end-users, provide templates. To receive notifications: Subscribe to specific event types using Team Foundation Event Web Services. Implement the Eventing Listener interface as a Web service API and expect calls from VSTF Eventing. To exercise fine grained control of event subscriptions, clients can implement custom subscription management tools that call VSTF Eventing Web Service API directly. Subscriptions to these events are done on an individual user basis. Each user defines which events to which he will subscribe by specifying the event type and a filtering condition. The product is expected to scale up to a thousands of users. Each user is expected to have a small number of subscriptions – usually less than 5. Defining Events The processes of defining and subscribing to events is as follows: Provide notification filtering from event metadata. Allow users the ability to add fields without the need to write any code. Provide an infrastructure for filtering in several ways from each event field. Provide sensible defaults for default subscriptions, but at the same time allow the subscriber the flexibility to choose any arbitrary filtering criteria. Events are defined through an XML Schema Definition (XSD) file. Fields in the event can be of any type including lists, as long as the type is serializable by the .NET XMLSerializer. This is easily achieved by making the fields public, by providing a no-argument constructor, and by not including cycles in the object graph. In general, every event schema should contain the following basic information. This is illustrated in the example below. Artifact URI(s) or Server URI: A string or list of URI(s) to the artifact(s) that are relevant for this event or the Server URI if the event does not affect an artifact. This information allows event recipients to uniquely identify the source server and artifact(s). Team Project URI(s): A string or list of URI(s) for the team project(s) this event (or its relevant artifact) relates to. This allows event recipients to uniquely identify the target team projects. This property may be omitted if the event pertains to the whole Team Foundation Server or if it does not pertain to any artifacts. Raising Events FireAsyncEvent method public void FireAsyncEvent (string theEvent) public void FireAsyncEvent (object theEvent)theEvent is the serialized XML or the serializable object for the event. Fires theEvent to the Eventing Service asynchronously. FireBulkAsyncEvents method public void FireBulkAsyncEvents(string[] theEvents) public void FireBulkAsyncEvents(object[] theEvents) theEvents is an array of serialized XML or the serializable objects for the events Fires the events in theEvents to the Eventing Service asynchronously. Subscriptions A user can subscribe to events by selecting the filter(s) he would like applied to the events, along with the delivery preferences. The user can choose to receive events immediately when they occur, or to have them consolidated and delivered on a regular schedule. Example filters: me for Defect events when the Defect Project field = “Visual Studio”, “Word”, or “Excel”. me for Check-in events when the Check-in Files field is Under “\dd\vset\eStudio” OR the Files field is Under “\dd\vset\eQA”. me for Defect events when the Defect Owner field = “user1” AND the Status field <> “Resolved”. Event subtypes containing any number of simple fields are supported. Events subtypes can contain sequences and other complex types. Fields can be referenced using XPath notation (such as “myObject/myfield”). Referencing a sequence in an expression matches if any of the objects in the sequence match. XPath functions can also be used to query the document. Operators For each field, the subscriber can choose to filter by using one of the predicates in the chart below. This is an initial list that can grow as needed. = (equals): Applies to - String, Int, Enum, Date, Bool < (less than): Applies to - Int, Enum, Date <=: Applies to - Int, Enum, Date > (greater than): Applies to - Int, Enum, Date >= : Applies to - Int, Enum, DateUnder (Quickly match file specs)String Match (Regular Expression Match): Applies to - String Like (Simple match): Applies to – String Equals can apply to a single value or to a range of values. Less than or equal and greater than or equal can be combined to select ranges of values. Under and Match are special string matching conditions. Under is for the common case that you need to match strings such as file paths that are hierarchical in nature. Match allows the subscriber to enter a regular expression that matches a given event string. Combinations A subscription is defined by a subscriber, an event, and a delivery mechanism such as . A subscription can have any number of filters. Filters can be combined with both and and or expressions. A condition can be negated with not. The following example would accept only events where the owner is “user1” and the file is in the eQA folder or a subfolder. Owner equals “user1” and Files under “\devdiv\vset\eQA” Combinations of any arbitrary complexity can be formed using parentheses. Subscription API Subscribe method int SubscribeEvent (string userid, string eventType, string filterExpression, DeliveryPreference preferences) string filterExpression, DeliveryPreference preferences, string tag) Adds a subscription to the Eventing Service. Users may have multiple subscriptions to the same event type. They will receive only one notification, regardless of the number of matching subscriptions. Returns the unique subscriptionId for the subscription. The subscriptionId can be used to unscribe. userId is an arbitrary string for identifying the user. It is used for looking up subscriptions by owner. In Beta 3, the Project Alerts set in Team Explorer use addresses for the userId. For the final release, the system will use SIDs. eventType is the fully qualified name of the event type to which the user is subscribing. filterExpressions is string that describes how to filter through many instances of this event type. Only events that match the filter are delivered. DeliveryPreference is a structure that has the following format. It describes how an event that matches the eventType and filterExpression is to be delivered. The filtering language is discussed in greater detail in a later section. class DeliveryPreference { enum Type; // Html, Plaintext Soap enum Schedule; // immediate, daily or weekly string Address; // address or SOAP URL depending on the Typeor other identifying string. } UnsubscribeEvent Method void UnsubscribeEvent (int subscriptionId) Removes the subscription with ID subscriptionId. EventSubscriptions Subscription[] EventSubscriptions (string userID) Subscription[] EventSubscriptions (string userID, string tag)Returns an array of the subscriptions associated with the userID. The optional tag limits the returned set of subscriptions to those that have been subscribed in association with the string tag. Notification Formatting There are two ways to format a notification. One is to use XSL to transform the event XML to the notification. The second is to use a custom template-based formatting. To use XSL formatting, create an .xsl file in the D:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\Services\v1.0\Transforms directory on the application tier. To use template formatting, create a .template file in the same directory. If both files exist in that directory for a given event type, the template file is used. Notification Delivery There are multiple delivery options that can be selected by the user as part of the subscription. Currently, Team System supports and Web Method calls. The events are persisted as XML in the database until all of the related notifications are delivered. Security Requirements Developers of tools might want control over the notifications a user can receive. For this purpose, they can implement an Eventing Service security plug-in. At two points, the tool can interject custom logic to limit the information available in an event, or deny notification of the event entirely. Tools can register one or more INotificationFilters and ISubscriptionPathValidators to provide checks during notification and subscription, respectively. These interfaces are defined in the Microsoft.TeamFoundation.Server assembly and should be implemented in a plug-in assembly that is placed, along with supporting assemblies, in the Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\Services\bin\Plugins directory on the application tier. At least one class in the assembly should have a default constructor and implement IPlugin (described below). At initialization time, the assembly is loaded, one object of each IPlugin is created, and Initialize() is called. At this time the plug-in registers either or both INotificationFilter and ISubscriptionPathValidator. INotificationFilter is used to alter the contents of an event (as an XML document) before the notification is generated. Each altered event is returned as a copy of the original event. ISubscriptionPathValidator is used to check whether a person has permission to subscribe to an area. For instance, if a “DefectChangedEvent” has a “ProjectPath” field, the validator can check whether a user has permission to subscribe to DefectChangedEvents where the ProjectPath references “\Root\DivisionExample\ProjectX.” See the Visual Studio 2005 SDK for more information.

Registering and Subscribing
Another tool may subscribe to receive events of that type when they are raised. We’ll use a utility that is delivered with Team Foundation. TFS Work Item Tracking Work Item Spawn Demo At setup time, a tool registers the types of events it will raise. TFS Work Item Tracking raises a WorkItemChanged Event subscribe unsubscribe Event Types Subs Registration API Subscription API Through UI (purpose-built or general), a person can subscribe to receive notifications. Not used in this demo

Notifications delivered through e-mail
Raising an Event Events matched to subscriptions Note: Server-side sinks only in V1. Demo “WorkItemSpawn” WS invoked. TFS Work Item Tracking fireAsyncEvent callback method specified in subscribe call Work Item Spawn Demo TFS Event Client TFS Event Engine Event Types Subs Subs Rules Processor Notifications delivered through Events matched to subscriptions TFS Work Item Tracking raises a WorkItemChanged Event

+ Event Subscriptions Specify an Event Build Completion Event
Build Status Changed Event BranchMovedEvent NodeCreatedEvent NodePropertiesChangedEvent NodeRenamedEvent NodesDeletedEvent ProjectCreatedEvent ProjectDeletedEvent CheckinEvent WorkItemChanged Filter Expression Eg: Visual Studio Event Filter Language + TeamProject = ‘MyProjectName’ AND PolicyOverrideComment <> ‘’ Event Subscriptions When you register your event subscription you must specify the event. The following is a list of available events you can subscribe to: Build Completion Event Build Status Changed Event BranchMovedEvent NodeCreatedEvent NodePropertiesChangedEvent NodeRenamedEvent NodesDeletedEvent ProjectCreatedEvent ProjectDeletedEvent CheckinEvent WorkItemChanged In most cases, you will want to provide a filter expression to further narrow down the conditions of your event notification. Provide Filter expressions to further specify the criteria for the event. For example, if you wished to be notified when team members override checkin policies for your project you would create an event subscription for the CheckinEvent and provide a filter expression such as: TeamProject = ‘My ProjectName’ AND PolicyOverrideComment <> ‘’ The above filter expression looks for checkin events for a project named “My Project” and when the Policy OverrideComment is not blank. When subscribing to events using the webmethod delivery method, your webservice method must match the following signature: [SoapDocumentMethod(Action = " RequestNamespace = " [WebMethod] public void Notify(string eventXml) {} The event data is sent as a XML document in the eventXml string parameter. The schemas for the event documents are available on the Team Foundation Server in this folder: C:\Program Files\Microsoft Visual Studio 2005 Enterprise Server\BISIISDIR\bisserver\events\EventSchemas If you use the XSD tool on one of the schema files to create a class that matches that schema, you can then convert the incoming event document into that object as follows: XmlSerializer xs = new XmlSerializer(typeof(CheckinEvent)); StringReader sr = new StringReader(eventXml); CheckinEvent CheckIn = xs.Deserialize(sr) as CheckinEvent; The CheckinEvent class was generated by the XSD tool against the CheckinEvent schema (XSD).

TFS Linking Service vstfs:///<toolType>/<artifactType>/<toolSpecificID> Summary The Linking Service is offered as part of Team Foundation Core Services. It is a lightweight architecture for allowing loosely-coupled and individually-architected tools to offer simple data integration through a combination of technology and conventions. The VSTF Linking Service thus provides some of the core benefits that a common repository offers without the repository itself. For example, the suite of tools that make up Microsoft® Visual Studio 2005® Team System, version 1.0 includes version control and work item tracking tools. Each of these tools was designed separately with different principles in mind. Introducing a standard way to identify the major items, known as artifacts that each tool makes available allows work items to link to source control items and vice versa without requiring that either tool possess detailed information about the other. Likewise, third-parties can introduce new tools to Team System with their own specialized links to enable lightweight data integration without making any modifications to Team System tools. The primary benefits of the linking service include: Ease of data integration for new tools New tools that third parties introduce into the Visual Studio Team System environment can integrate data with Visual Studio Team System by conforming to a small set of conventions and implementing a fairly simple API. Discoverability of links and artifacts Tools register artifact types and link types with Team Foundation, so any authorized program can discover through the Team Foundation administrative APIs. Common behaviors and UI elements While Team Foundation does not prevent a tool from using links in situation-specific, tightly-coupled ways, a tool can also take advantage of the generic behaviors that Team Foundation requires each artifact provider and consumer to provide in order to use links in loosely-coupled ways. Scenarios A user wants to see all items of all types that are tied to some artifact—for example, everything related to a specific work item, The Linking Service returns a full typed list of all the artifacts linked to the subject artifact in displayable form when provided with the Uniform Resource Identifier (URI) of the work item. The list includes artifacts for which the artifact provider—in this case, the tool responsible for work items—does not have information. Well-Formed VSTF URIs The identifier for an artifact consists of a well-formed VSTF URI. Each VSTF URI is formed by the provider for the artifact. The following discussion identifies each element of the URI and explains how its value is derived. The following example shows a prototype of a well-formed VSTF URI: vstfs:///<tooltype>/<artifacttype>/<tool-specific id> vstfs is a constant that, in future, may be used as a custom protocol. In version 1.0, it is converted to a URL and made widely available that way. <tooltype> identifies the tool interface supported by the tool responsible for maintaining and answering questions about the artifact—in other words, the artifact provider. This enables a calling tool (one holding a link) to make decisions about how to handle an artifact based on the interface offered by the tool. For example: vsbug, vsversionstore, etc. Tooltype identifies the API and is specified by the tool. <artifactttype> is the type of artifact that the tool maintains. A tool only supplies an artifact type if the type is immutable. Artifact types are registered by the tool at installation time. <tool-specific id> is an immutable reference to the artifact instance. The tool-specific ID is created and maintained by the tool. Examples: URI pointing to a file stored in source control: vstfs:///vsversionstore/file/b4e3216 URI pointing to requirement record in work item tracking: vstfs:///vstfArtifact/vsworkitems/req/345 Loose Coupling vs. Tight Coupling In the Team Foundation linking environment, tools use links to enable loosely-coupled behaviors. Tools can also provide specialized interfaces and interactions that provide a higher-level of specialized integration through tightly-coupled behaviors. Each approach is valid in the proper context. Loose coupling offers these advantages: You can add new artifact types into a Web of artifacts without disturbing pre-existing applications. This is especially useful for third party integration. You can aggregate results to provide a complete “where-used” picture for artifacts of varying types. Artifact handlers, both providers and consumers, can change behaviors drastically and, as long as they continue to use the generic linking interfaces, all loosely-coupled behaviors will continue to work. Tools that offer tightly-coupled behaviors exploit links that conform to the linking service but they do not make use of generic linking interfaces. Instead, an artifact consumer takes advantage of specific interfaces offered by the artifact provider. These behaviors can be used to provide cross-tool behavior that is very specific to the participating tools. Loose coupling should be used when: A pointer to a referenced artifact can be present in a referring artifact unknown to the referenced artifact’s provider. For example: A third party test case management tool is introduced into the suite. The tool is Team Foundation-enabled and thus provides a mechanism to build links to Visual Studio Team System defects. The Visual Studio Team System defect does not need to know about this new type of referring artifact to show return information about it in an inversion query. A referring artifact can point to a referenced artifact type that the referring artifact does not know about. This mechanism requires a generic artifact picker that is not planned for version 1.0. The behaviors available for a referenced artifact are not influenced by the referring artifact. For example: When a user wants to see what work items are associated with a build inside the Visual Studio integrated development environment (IDE), the list of work items is returned in the inversion query UI for the build. Likewise, when a user wants to see the work items that were affected by a specific changeset, a list of work items is returned in the inversion query UI for the changeset. In either case, the user should be able to double-click any of the work items and a Work Item Tracking document window for that window will be displayed. The desired behavior is exactly the same whether the referring artifact is a build or a changeset; thus the behavior is not influenced in these two cases by the referring artifact. Loosely-coupled interactions are enabled through artifact providers and consumers by: Following Team Foundation conventions. Implementing standard interfaces. How Tools Participate in Linking Each tool that offers artifacts is an artifact provider. An artifact provider must register its artifact types and must implement a set of interfaces that enable a loosely-coupled tool to read those artifacts. Artifact provider responsibilities are described in Artifact Provider Obligations. An artifact provider that also contains links to other artifacts is an artifact consumer. An artifact consumer has some additional obligations beyond those of a provider. An artifact consumer must register link types and offer standard methods to answer queries and inversion queries. Responsibilities of an artifact consumer are described in Artifact Consumer Obligations. Finally, VSTF provides a number of facilities for registration, discoverability, and cross-service link query. These facilities are described below. Artifact Provider Obligations Any tool that hosts artifacts is an artifact provider. An artifact provider has the following responsibilities; some are optional, others are mandatory. These are discussed in detail in subsequent sections. Artifact Provider At registration time, each artifact provider: Must register each artifact type it hosts with Team Foundation Core Services. Must register any events it can raise, including artifact change events. Must register the URL of its provider Web service interface in the Service Interfaces area of Team Foundation Server registration. Each artifact provider: Must offer an interface that can return the VSTF URI for each artifact it owns. For more information, see Well-Formed VSTF URIs. Must implement ILinkingProvider on the registered provider web service interface and offer a GetArtifacts method that can be used to retrieve instances of each artifact type it owns. Should include a URI for an artifact as a return value in each method that returns an artifact instance. For more information, see Well-Formed VSTF URIs. Must raise an event when an artifact it owns is created, deleted, or changed in a way that causes a GetArtifacts method execution for that artifact to return a different result. Should offer an ASP-based way to handle external addressability for each artifact type it provides. For more information, see External Addressability. May implement a client API that responds to in-the-IDE requests for artifacts it owns (ExecuteDefaultAction). Team Foundation Core Facilities and others can use it to provide uncoupled access between an artifact consumer and provider. Artifact Type Registration Registration of artifact types and link types can take place at installation time or dynamically at run time. The following information is required for each artifact type: Tool (artifact provider) responsible for artifacts of this type Artifact type name, which is not localizable Artifact type label, which is localizable The following information is required for each link type: Artifact type name of referring artifact Link type name, which is not localizable Link type label, which is localizable Inverse link type label, which is localizable An optional referenced artifact types array Remarks: Link type label: forward and inverse are used to provide readings in either direction; for example, man bites dog, dog is bitten by man. If the referenced artifact types array is empty, the referenced end of the link is untyped. That is, links of this type may point to any artifact. Each element in the referenced artifact types array indicates both the referenced artifact type’s service and the referenced artifact type’s name. Provider API All artifact providers must implement the interface ILinkingProvider found in the Microsoft.TeamFoundation.Server namespace in the ILinkingProvider on their registered web service inteface. The only method required for this interface is GetArtifacts. The artifact provider may also implement the IClientLinking interface in the same namespace on the client-side, which includes the ExecuteDefaultAction method described in this section. This method allows a caller to navigate to and display the artifact without any knowledge of the artifact or the artifact’s type. Change Events When an artifact changes, the provider may raise an async change event to the Eventing Service using either the FireAsyncEvent or the FireBulkAsyncEvents methods. The event type needs to be registered with the Team Foundation Server and must conform to the Generic Artifact Schema. Since the Generic Artifact Schema includes an artifact’s outgoing links, these events inform listeners of link changes as well as other artifact changes. An event should be raised whenever an artifact is added, changed, or deleted. The Generic Artifact Schema includes an attribute on the Artifact element that enables a caller to indicate whether the artifact it contains was added, changed or deleted. Figure 4 illustrates two changes reported in a single event: Defect 152 has been added and Requirement 153 has been deleted. Note that different event types may be raised for artifact additions, changes, and deletions if appropriate. Artifact Consumer Obligations Artifact Consumer At registration time, each artifact consumer: Must register each link type it hosts with VSTF. Must register the URL of its consumer Web service interface. Should subscribe to any events to which it can respond, including artifact change events. Each artifact consumer: Must offer GetReferencingArtifacts methods that can respond to “do you point to me?” queries. Should respond to ArtifactChanged events; for deletes, the referring artifact link should be deleted. For changes, the referring artifact can check for a situation that might cause the link to be invalidated. Consumer API An artifact consumer must implement the ILinkingConsumer interface defined in the Microsoft.TeamFoundation.Server namespace on its registered web service. This interface defines only one method Artifact[] GetReferencingArtifacts (string[] artifactUris) The GetReferencingArtifacts takes an array of Uris as input. The return value is an array of all Artifact objects that reference or link to one or more of the the input artifact Uris. Artifact Change Event Handler As described above, each time an artifact materially changes, the artifact provider should raise a change event. Each artifact consumer should listen for these events by registering a matching event subscription. The event handler for each consumer must inspect the event to determine whether it holds artifacts of interest. If it does, the event handler for the consumer can then respond to the change. Normally, such a response takes one of the following forms: In the case of a delete the consumer must remove any links to the deleted artifact. In the case of a change the consumer in which there is a value for PreviousUri that is different from the value of Uri, the consumer must replace all pointers it holds to PreviousUri with pointers to Uri. In some cases, there may be specific policy information that requires that the referenced artifact be in a specific state for the referring artifact to hold a link to it. If so, the consumer can ensure that after the change the referenced artifact is still in the correct state; otherwise, the consumer removes its links. Aggregating Artifacts It would be difficult to discover certain artifacts and relationships if a caller had to poll all registered artifact providers and consumers one at a time for a list of each constituent’s artifacts and relationships. To simplify this, the TeamFoundationServer API provides a client-side only linking service that aggregates artifacts and relationships for callers. Invocation is as follows. TeamFoundationServer server = TeamFoundationServerFactory.GetServer(serverName); ILinking linking = (ILinking) server.GetService(typeof(ILinking)); The ILinking interface returned from the server implements the ILinkingProvider and ILinkingConsumer interfaces along with two additional methods detailed below. The caller can use this returned interface like any other client-side linking provider or consumer interface, except that the instance returned from the TeamFoundationServer object aggregates all the artifacts and relationships on the server. This works as follows: When getting an artifact with Uri X, this client-side service looks through all registered web services for providers that register Uri’s matching X. It calls each such provider and aggregates the results before returning them to the caller. When getting a list of referencing artifacts, this client-side service similarly inspects all registered web services for artifact consumers that register the specified artifacts. It then calls each such consumer and aggregates the results before returning them to the caller. The ILinking interface implements ILinkingProvider and ILinkingConsumer and additionally includes the following methods. It is found in the Microsoft.TeamFoundation.Server namespace. Artifact[] GetReferencingArtifacts (string[] artifactUris, LinkFilter[] filters) This version of GetReferencingArtifacts takes an array of referenced artifact Ids and an array of link filters. Link filters can be used to restrict the returned artifacts by tool type offering the artifact, artifact type, or link type (see “LinkFilter Class” below). string GetArtifactURL(string artifactUri) This method is described in the “External Addressability” section earlier. Note that although programmatic aggregation of links through these APIs is supported, aggregation of links in the out-of-the-box Team Explorer UI is not. The control that shows link types on work item forms displays a fixed set of link types and cannot be extended. Internationalization As mentioned in Artifact Type Registration, the registration database contains three types of localizable strings that pertain to linking: The artifact type label The link type label The inverse link type label Neither the Linking Service nor any VSTF-enabled tools are required to return these labels as part of a query result, because the Linking Service and tools can discover these labels easily by looking at the registration service tables by using GetRegistrationEntries. VSTF caches the labels locally, so the call is low cost. Security Considerations Artifact providers and consumers should respect ACLs on artifacts and only return artifacts to which the calling account has read permissions when implementing these methods Artifact[] GetArtifacts (string[] artifactUris) Thus, GetArtifacts should only return artifacts for artifact URIs to which the caller has read permissions. GetReferencingArtifacts should only return artifacts that refer to the specified artifact URIs and to which the caller has read permissions. There should be no distinction between artifacts to which the caller lacks read permissions and artifacts that do not exist. The corresponding element for these artifacts will appear as null in the returned arrays. Artifacts[ ] ILinking.GetReferencingArtifacts(string[] artifactUris)

TFS Security Service Group Security Service Authorization Service
The security services consist of two core Team Foundation Server Web services: the Group Security Service and the Authorization Service. These Web services are exposed on the application tier and are consumed through APIs that are sub-services of the TeamFoundationServer client-side object model. The client side APIs are designed to be the primary interface for managing Team Foundation Server security for third-party tools. Group Security Service The Group Security Service enables consumers to manage Team Foundation Server application groups; the central mechanism by which all users and groups are managed on the server. This service can be used independently of the Authorization Service. Regardless of whether the Team Foundation-provided authorization is used or the consumer implements their own authorization logic, this service can be used for querying group memberships for subsequent permission evaluation. In fact, the Version Control components of TFS authorize path-level permissions independently of the Authorization Service, but query for group memberships against the Group Security Service. TFS Application Groups TFS application groups are at the heart of the Group Security Service. They are the containers for all users and groups. No user can connect to a Team Foundation Service without being a member, directly or indirectly, of some application group on the server. Members Application groups can contain Windows and Active Directory identities. Refer to the list of supported members below. Suppose a Windows user AdventureWorks\JAaberg is a member of the AD security group AdventureWorks Staff. Then AdventureWorks\JAaberg is a member of the TFS application group Users if AdventureWorks Staff is a member of this group. Other TFS application groups Any Active Directory object Active Directory Security Groups (no other Active Directory container types) Windows User on the Local Machine Windows Group on the Local Machine Name and SID Every application group has a friendly name and SID. The name can be changed over time, but the SID is generated when the application group is first created and can never be changed. An application group name can contain any Unicode character except the following characters. \ / : * ? " < > | 0x09 (HT) Application group SIDs are guaranteed to be unique within a Team Foundation Server. Scope Application groups can be scoped to a Team Foundation Server or a team project. Those scoped to a team project are not visible in other team projects on the server. Application group names are unique within their scope. Special Types There are three special types of Team Foundation Server application groups. Administrative Groups These application groups have implicit irrevocable rights associated with them; they are automatically created by the application and cannot be deleted by a user. There is one administrative group per Team Foundation Server and one administrative group per team project. These groups cannot be manually added. The former is created at setup time, the latter is created with the project and the Windows user who creates the project is added to the group automatically (this initial user can later be removed). Service Accounts Service application groups are also created at setup time and cannot be deleted. There is always one service application group called Service Accounts per Team Foundation Server. These groups cannot be manually added. Team Foundation Valid Users The Team Foundation Valid Users is a special type of Team Foundation Server-scoped application group which is pre-created at setup time and cannot be deleted. It cannot be manually created and contains all other application groups on the Team Foundation Server and therefore, directly or indirectly, contains all identities registered to the Team Foundation Server. Its members are maintained dynamically and cannot be modified by the user. API To access the application groups and their members on a Team Foundation Server, the caller invokes an instance of the GroupSecurityService interface as follows. using Microsoft.TeamFoundation.Client; using Microsoft.TeamFoundation.Server; ... TeamFoundationServer tfs = null; string serverName = "My TFS"; tfs = TeamFoundationServerFactory.GetServer(serverName); tfs.EnsureAuthenticated(new UICredentialsProvider()); s_IGroupSecurityService = (IGroupSecurityService) tfs.GetService(typeof(IGroupSecurityService)); The caller can then invoke methods on this instance to view and manage Team Foundation Server application groups and their members. The Identity type is at the center of all these calls, as it is the generic type that represents all Team Foundation Server application groups and supported member types be they Active Directory Security Groups or Windows Users on the local machine. Consult the reference section to learn more about this type. Listing Application Groups and Members Use the method below to list all application groups in a team project. If projectUri is null or empty, this method will list all application groups scoped to the serve. Identity[] ListApplicationGroups(string projectUri) Use the Members[] property of each Identity to list its members. To determine if an identity with SID userSID is a direct or indirect member of an identity with SID groupSID, use the method below. Note that the SIDs can specify any supported identity type and are not limited to users or groups. bool IsMember(string groupSID, string userSID) Working with Cache Because Team Foundation Server application groups can contain identities maintained elsewhere in Active Directory or on the local machine, these external identities are cached on the Team Foundation Server for performance optimization. The Group Security Service polls Active Directory and the local machine on a regular basis to update its cache. It also updates the cache on a cache miss. Because the cache can be out of date, it is sometimes desirable to make a slower call and read the identity properties directly from the source. The method below is used to read an identity from its source. It works similarly to ReadIdentity and updates the cache on all reads as well. Identity ReadIdentityFromSource(SearchFactor factor, string factorValue) The following method checks if an Identity is cached at all. bool IsIdentityCached(SearchFactor factor, string factorValue) Authorization Service The Authorization Service provides consumers with an access control system for the Team Foundation Server. The Authorization Service is used to register securable objects and grant, deny, or check permissions on those objects. It is the preferred method of control for other Team Foundation services. However, consumers such as the TFS Version Control service can augment this system by implementing their own authorization logic. Although consumers can implement custom authorization logic, the Group Security Service should still be used for resolving group membership queries to enable centralized administration of identities on the Team Foundation Server. Invocation The invocation below instantiates a new Authorization Service from the Team Foundation Server API. s_IAuthorizationService = (IAuthorizationService) tfs.GetService(typeof(IAuthorizationService)); If a method cannot be successfully executed, an exception is thrown. For more information see the Visual Studio 2005 SDK.

Version Control API Common Classes/Methods
Namespace: Microsoft.TeamFoundation.VersionControl.Client VersionControlServer CreateWorkspace, GetWorkspace QueryHistory, QueryLabels, QueryMerges, QueryPendingSets, QueryShelvedChanges Events: BeforeCheckinPendingChange, BeforeShelvePendingChange, BeforeWorkItemsUpdate,Conflict, Getting, Merging, NonFatalError, ResolvedConflict, WorkItemUpdated (and more) Workspace Get, CheckIn, Delete, Merge, Update, Shelve, UnShelve, Undo PendAdd, PendBranch, PendDelete, PendEdit, PendRename, PendUndelete QueryPendingSets, QueryShelvedChanges Version Control API The Version Control API is the primary interface by which you can access the Version Control services in Team Foundation Server. The primary objects are TeamFoundationServer – this is the root object from which you obtain a service, such as version control or work item tracking VersionControlServer – this is the primary interface to the version control server for operations and queries that are not specific to a workspace Workspace – this object represents a workspace and is used to pend changes, check in changes, and perform queries specific to a workspace Workstation – this object represents the current computer and manages the workspace cache, which contains the list of local paths in each workspace Code Samples Basic Team Foundation Version Control client API example Displaying the labels on a file, including label comments Displaying the sizes and dates of files in the server Sample checkin policy: make sure the comment isn't empty Show all pending changes on the Team Foundation server older than a given age Scanning history for the changesets that had policy override - simple usage of QueryHistory Code Sample: using System; using System.Collections.Generic; using System.Diagnostics; using System.IO; using System.Text; using Microsoft.TeamFoundation.Client; using Microsoft.TeamFoundation.VersionControl.Client; namespace BasicSccExample { class Example { static void Main(string[] args) { // Verify that we have the arguments we require. if (args.Length < 2) { String appName = Path.GetFileName(Process.GetCurrentProcess().MainModule.FileName); Console.Error.WriteLine("Usage: {0} tfsServerName tfsTeamProjectPath", appName); Console.Error.WriteLine("Example: {0} Environment.Exit(1); } // Get a reference to our Team Foundation Server. String tfsName = args[0]; TeamFoundationServer tfs = new TeamFoundationServer(tfsName); // Get a reference to Version Control. VersionControlServer versionControl = (VersionControlServer) tfs.GetService(typeof(VersionControlServer)); // Listen for the Source Control events. versionControl.NonFatalError += Example.OnNonFatalError; versionControl.Getting += Example.OnGetting; versionControl.BeforeCheckinPendingChange += Example.OnBeforeCheckinPendingChange; versionControl.NewPendingChange += Example.OnNewPendingChange; // Create a workspace. Workspace workspace = versionControl.CreateWorkspace("BasicSccExample", versionControl.AuthenticatedUser); try { // Create a mapping using the Team Project supplied on the command line. // Get the files from the repository. workspace.Get(); // Create a file. String topDir = Path.Combine(workspace.Folders[0].LocalItem, "sub"); Directory.CreateDirectory(topDir); String fileName = Path.Combine(topDir, "basic.cs"); using (StreamWriter sw = new StreamWriter(fileName)) { sw.WriteLine("revision 1 of basic.cs"); } // Now add everything. workspace.PendAdd(topDir, true); // Show our pending changes. PendingChange[] pendingChanges = workspace.GetPendingChanges(); Console.WriteLine("Your current pending changes:"); foreach (PendingChange pendingChange in pendingChanges) { Console.WriteLine(" path: " + pendingChange.LocalItem + ", change: " + PendingChange.GetLocalizedStringForChangeType(pendingChange.ChangeType)); } // Checkin the items we added. int changesetNumber = workspace.CheckIn(pendingChanges, "Sample changes"); Console.WriteLine("Checked in changeset " + changesetNumber); // Checkout and modify the file. workspace.PendEdit(fileName); using (StreamWriter sw = new StreamWriter(fileName)) { sw.WriteLine("revision 2 of basic.cs"); } // Get the pending change and check in the new revision. pendingChanges = workspace.GetPendingChanges(); changesetNumber = workspace.CheckIn(pendingChanges, "Modified basic.cs"); Console.WriteLine("Checked in changeset " + changesetNumber); } finally { // Delete all of the items under the test project. workspace.PendDelete(args[1], RecursionType.Full); PendingChange[] pendingChanges = workspace.GetPendingChanges(); if (pendingChanges.Length > 0) { workspace.CheckIn(pendingChanges, "Clean up!"); } // Delete the workspace. workspace.Delete(); } } internal static void OnNonFatalError(Object sender, ExceptionEventArgs e) { if (e.Exception != null) { Console.Error.WriteLine("Non-fatal exception: " + e.Exception.Message); } else { Console.Error.WriteLine("Non-fatal failure: " + e.Failure.Message); } } internal static void OnGetting(Object sender, GettingEventArgs e) { Console.WriteLine("Getting: " + e.TargetLocalItem + ", status: " + e.Status); } internal static void OnBeforeCheckinPendingChange(Object sender, ProcessingChangeEventArgs e) { Console.WriteLine("Checking in " + e.PendingChange.LocalItem); } internal static void OnNewPendingChange(Object sender, PendingChangeEventArgs e) { Console.WriteLine("Pending " + PendingChange.GetLocalizedStringForChangeType(e.PendingChange.ChangeType) + " on " + e.PendingChange.LocalItem); } } }

Team Foundation Object Model

6/16/ :48 AM Team Build 客户化 50 © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Team Build 架构 TF Client Build Server TFS TFS Data Tier
Team Build Client Build Configuration files - MSBuild Scripts Build request and Reports Build Server Build start/stop Team Build Service Build events Source Control Team Build Build sources and scripts MSBuild Scripts and targets Build Drop site Work item Tracking Open and Update bugs Team Build logger Static Analysis & Testing Build and Test data TFS Build Events Team Build Store TF Warehouse TFS Data Tier

Team Foundation Build 配制文件
MSBuild format XML 文件 Target element Task element UsingTask element 以下两个文件控制Team Build的过程 Microsoft.TeamFoundation.Build.targets TfsBuild.proj

Target 执行顺序 BeforeEndToEndIteration* BuildNumberOverrideTarget*
InitializeEndToEndIteration BeforeClean* CoreClean AfterClean* Clean InitializeBuild BeforeGet* InitializeWorkspace CoreGet AfterGet* PreBuild BeforeCompile* CoreCompile AfterCompile* Compile GetChangeSetsAndUpdateWorkItems PostBuild BeforeTest* CoreTest AfterTest* Test PackageBinaries* TeamBuild BeforeDropBuild* CoreDropBuild CopyLogFiles AfterDropBuild* DropBuild AfterEndToEndIteration* EndToEndIteration

Team Build客户化创建 Build Type 创建自定义 Tasks using System;
using Microsoft.Build.Utilities; namespace MyTasks { public class SimpleTask : Task public override bool Execute() return true; }

Team Build客户化签出 TfsBuild.proj 文件注册 Task <UsingTask
TaskName="MyTasks.SimpleTask" AssemblyName="MyAssembly.Build.Tasks"/> -Or- AssemblyFile="MyAssembly.Build.Tasks.dll"/> TaskName="MyTasks.SimpleTask" AssemblyFile="c:\somediskpath\MyAssembly.Build.Tasks.dll"/>

Team Build客户化调用 Task 签入 TfsBuild.proj 文件签入 Task .dll
<Target Name="BeforeGet"> <SimpleTask /> </Target> 签入 TfsBuild.proj 文件签入 Task .dll

可扩展性 Toolkit Extensibility Presentations
Process Template Customization Reporting Customization Team Build Extensibility Team Explorer and Process Extensibility Team Foundation Core Services Extensibility Test Tool Extensibility Version Control Extensibility Work Item Extensibility Available from The Visual Studio 2005 SDK The Visual Studio 2005 SDK contains an entire section devoted to Team System. The SDK contains the following information: Extensibility Presentations Process Template Customization guidance and code samples Reporting Customization guidance and code samples Team Build Extensibility code guidance Team Explorer and Process Extensibility guidance and code sample Team Foundation Core Services Extensibility guidance and code samples Test Tool Extensibility code samples Version Control Extensibility api reference and code samples Work Item Extensibility guidance and code samples

网络资源书籍 Working with Visual Studio 2005 Team System Professional Visual Studio 2005 Team System Software Engineering with Microsoft Visual Studio Team System

与本次主题有关的Session和活动 DEV 331 Visual Studio Team Edition for Database Professionals 概述 HOL DEV Visual Studio Team Edition for Database Professionals

填反馈表

DEV332 Visual Studio Team Foundation Server 客户化与可扩展性分析

Similar presentations

Presentation on theme: "DEV332 Visual Studio Team Foundation Server 客户化与可扩展性分析"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

DEV332 Visual Studio Team Foundation Server 客户化与可扩展性分析

Similar presentations

Presentation on theme: "DEV332 Visual Studio Team Foundation Server 客户化与可扩展性分析"— Presentation transcript:

Similar presentations

About project

Feedback