Define the tasks to process a plug-in

Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

You use the tasks element and its child elements to define the artifacts to be uploaded or specific elements to be created for a plug-in. A task specifies work that must occur to configure something specific to the process in a new project. A number of the tasks that you define upload the work item types, work item queries, documents, and reports for a project. Other tasks that you can define configure other areas of Visual Studio Application Lifecycle Management, such as Team Foundation Build, Visual Studio Lab Management, Test Manager, and Team Foundation version control.

Tasks Syntax Structure

You can specify several tasks within a plug-in, and these tasks may have dependencies on one another. The tasks that you define for each plug-in must conform to the schema definition for tasks, defined in the Tasks.xsd file, and be specified in its own file using the tasks container element.

The following syntax shows the high-level structure of the tasks element and its child elements.

         <dependency />  
        . . .          
      </dependencies />  
        . . .          

Tasks element reference

The following table describes each element that can define the tasks for a plug-in.


Description and syntax


Optional child element of task. Specifies other groups on which a group depends.

<dependency>. . . </dependency>


Optional child element of dependencies. Specifies the ID of another task on which this task depends. The other task must complete before this task can start.

<dependency taskId="taskId" />


Optional child element of taskXml element for the Build and Lab plug-ins. Specifies the name, location, and destination of a file to upload to support build processes for a project.

<ProcessTemplate Type="FileType" Filename="LocalPathAndFileName" 
Description="FileDescription" ServerPath="UploadLocation" />

Where each attribute is defined as follows:

  • Type: The type of file that is being uploaded. The following values are valid: Default and Upgrade for build template files and Custom for lab template files.
  • Filename: The local directory path and name of the file to upload.
  • Description: A short text string that describes the file to upload.
  • ServerPath: The path of the server that is running Team Foundation Server where the file should be uploaded. The only valid upload location is $/$$PROJECTNAME$$/BuildProcessTemplates.


Required child element of tasks. Specifies work that must occur to configure something specific to the process in a new project.

<task id="task id" name="name of task"      plugin="Microsoft.ProjectCreationWizard.PluginName" 
<dependencies> . . . </dependencies>
<taskXml> . . . </taskXml>

Where each attribute is defined as follows:

  • Type: id: Specifies a name that identifies the task. If another task depends on this task, it references this ID. You must assign a unique value for the ID within the plug-in file.
  • name: Describes what the task does.
  • plugin: Identifies which plug-in must run this task.
  • completionMessage: Specifies the message to display during project creation to indicate that the task completed successfully. Maximum length is 256 characters.
  • completionDescription: Specifies the message to display during project creation to indicate that the task is being processed. Minimum length is 1 character.


Required child element of taskXml. Contains a collection of task elements that each specify work that must occur to configure something specific to the process in a new project.

<task/>. . . </task>
</tasks />


Required root element for a plug-in file. Describes the work that is required to complete this task. The XML inside this element block varies and is specific to each plug-in.


The XML processor does not try to validate the content within the element.

<taskXml> . . . </taskXml>

Index to taskXML Elements by Function

For more information about the specifics of the XML markup elements that you can specify for each plug-in, see one of the following topics:

Example: Define work item types

The following example shows a task that creates six types of work items by referencing the definition files for each type.

   name="WorkItemType definitions"  
   completionMessage="WorkItemTypes created"           
   completionDescription = "Processing work item types used by work item tracking">  
        <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Bug.xml" />  
        <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\SharedStep.xml" />  
        <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Task.xml" />  
        <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\TestCase.xml" />  
        <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\UserStory.xml" />  
        <WORKITEMTYPE fileName="WorkItem Tracking\TypeDefinitions\Issue.xml" />