How to: Create an Automated Build and Deployment Solution with Team Foundation Server Team Build

  • Article
Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

This topic demonstrates how to automatically build and deploy SharePoint solutions with Microsoft Visual Studio Team System 2008 Team Foundation Server Team Build Services. It assumes that the SharePoint solutions were created with Visual Studio extensions for Windows SharePoint Services (also referred to as "extensions" in this topic). The topic describes the required files and artifacts and also demonstrates how to create a custom SharePoint target file. This topic has the following system requirements:

  • Visual Studio Team System 2008
  • The DDFGenerator tool. It should be installed on the build server.

The following procedure summarizes the steps that are required to automatically build and deploy the SharePoint solutions.

To create an automated solution

  1. Understand the Web solution package.
  2. Add the PKG folder to source control.
  3. Build and deploy the SharePoint solution.
  4. Add the solution folder and the Setup.bat file to source control.
  5. Create the SharePoint.targets file:
    1. Add the PropertyGroup section.
    2. Add the ItemGroup section.
    3. Add the Targets section:
      1. Create the GenerateDDF target.
      2. Create the PackageWSP target.
      3. Create the DeploySolution target.
      4. Create the RetractSolution target.
  6. Create a TFSBuild.proj file.
    1. Import the SharePoint.targets file.
    2. Override the SharePoint targets properties.
    3. Call the targets.
    4. Prepare a SharePoint site.

The following sections correspond to each of these steps. There is also an Examples section that contains examples of a SharePoint.targets file and a TFSBuild.proj file.

Understanding the Web Solution Package

A Web solution package (WSP) is the primary way to deploy custom SharePoint features and components in Windows SharePoint Services 3.0. A WSP is a CAB file that has a .wsp file name extension. It contains a manifest that is named Manifest.xml and all the SharePoint solution artifacts that are necessary for deploying a SharePoint solution.

You can manually create a Web solution package and create and maintain the manifest file and the feature files yourself if you do not want to use the extensions. After you are ready to deploy your SharePoint solution, use the Makecab.exe tool (MakeCab) to create the WSP. For more information about how to manually create WSP files, see Creating a Solution on MSDN.

The Training Management application's SharePoint solution (this is created from the Contoso.TrainingManagement project) is created with the extensions. This means that the extensions generate the manifest and the feature XML files. One advantage of using the extensions is that developers do not need to maintain a large number of XML files. The challenge is that the extensions complicate the process of rebuilding a WSP in an automated environment.

The rest of this topic discusses how to create an automated build and deployment system. The code for the pertinent files and targets is included within the appropriate sections.

Adding the PKG Folder to Source Control

The extensions provide a Visual Studio plug-in named the WSP View that allows developers to see the WSP structure and the auto-generated Feature.xml files. Developers can customize this structure and update the files. The WSP structure is contained in a folder named pkg that is located under the project folder. The pkg folder is regenerated when the WSP view is refreshed and when you right-click the Visual Studio solution and then click Deploy. To permit team development, you must add this folder to the source control repository. This makes any WSP structure customizations that one developer performs available to the other developers on the team.

Building and Deploying the SharePoint Solution

After you add the pkg folder to source control, you can create the SharePoint solution that you want to deploy. First, click Build Solution on the Visual Studio Build menu. After the Visual Studio solution compiles, click Deploy Solution on the Build menu.

The Deploy Solution command replaces any temporary GUIDs with actual type names. It also generates a Setup.bat file that contains the STSADM commands that are required to install the WSP and activate the SharePoint features.

Adding the Solution Folder and the Setup.bat File to Source Control

The solution is located in a folder named solution under the bin\debug folder. This folder is regenerated when the SharePoint solution is deployed. The extensions do not allow you to automate the action of selecting Deploy Solution. You must manually regenerate the solution folder. This folder and the Setup.bat file must be placed under source control so that a build process can use these files to generate a .wsp file and deploy it. It is not necessary to add compiled assemblies to source control. These assemblies are built by the build process. Developers should locally deploy and test their SharePoint solutions before placing the solution folder into source control.

Creating the SharePoint.targets File

In MSBuild, targets group specific tasks together. Tasks provide the procedures that run during the build process. For information about creating MSBuild targets files, see MSBuild Targets on MSDN. The Training Management application uses a custom targets file that is named SharePoint.targets. It collects the SharePoint build tasks in a single place. In addition to organization, another advantage to targets files is that a custom targets file can be reused to deploy other SharePoint solutions. The following code shows the outline of the file.

<?xml version="1.0" encoding="utf-8"?>

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">
      …
</Project>

Adding the Property Groups Section

The SharePoint.targets file includes a PropertyGroup section that defines some of the necessary variables. The following code shows the PropertyGroup section.

<PropertyGroup>
    <!-- Path to the DDFGenerator tool -->
    <DDFGeneratorDir></DDFGeneratorDir>
    <!-- Indicate where the Project's bin\debug folder is. MUST BE OVERRIDEN IN TFSBuild.proj! 
         This must be the debug folder because that is where the VSeWSS solution folder is checked in -->
    <ProjectTargetDir></ProjectTargetDir>
    <!-- Path to the solution folder in the project -->
    <VSeWSSSolutionDir>$(ProjectTargetDir)\solution</VSeWSSSolutionDir>
    <!-- Path of the bin\(debug|release) folder to locate all of the binaries -->
    <BuildBinariesDir>$(BinariesRoot)\Debug</BuildBinariesDir>
    <!-- The name of the WSP listed in the setup.bat file. 
         This property should be overriden in the TFSBuild.Proj file for a custom name -->
    <WSPPackageName></WSPPackageName>
    <!-- Location to copy the files after successful build/package/test -->
    <TestDropDir></TestDropDir>
    <!-- Path to the STSADM tool -->
    <StsAdmWorkingDir>%commonprogramfiles%\Microsoft Shared\web server extensions\12\bin</StsAdmWorkingDir>
    <!-- Path to the IISAPP.VBS file -->
    <IISAppScript>&quot;C:\WINDOWS\system32\iisapp.vbs&quot;</IISAppScript>
    <!-- Name of the application pool in IIS for the SharePoint test site -->
    <SharePointTestAppPool>SharePoint - 80</SharePointTestAppPool>
    <!-- The Site Template code name of the Site Definition to create a site off of -->
    <SharePointSiteTemplateName></SharePointSiteTemplateName>
    <!-- The Site Template code name of the Site Definition to create a site off of -->
    <SharePointSiteTitle>Home</SharePointSiteTitle>
    <!-- The siteUrl of the SharePoint site to deploy to-->
    <SharePointSiteUrl>https://localhost</SharePointSiteUrl>
    <!-- The relative webUrl of the SharePoint site to create and deploy to -->
    <SharePointWebUrl></SharePointWebUrl>
</PropertyGroup>

Adding the ItemGroup Section

The ItemGroup section groups together Item elements. These represent inputs into the build system. This is shown in the following code, which is located in the SharePoint.targets file. Note that the code contains sample values. You will need to adapt the code to your own situation.

<ItemGroup>
    <!-- Collection of assemblies that are to be included in the WSP -->
    <AssembliesToPackage Include="$(BuildBinariesDir)\*.dll"/>
    <!-- Collection of files that are to be included in the WSP -->
    <SolutionItemsToPackage Include="$(VSeWSSSolutionDir)\**\*.*" />  
</ItemGroup>

Adding the Targets Section

Add a Targets section to the SharePoint.targets file. This is shown in the following code.

<Target>
  …
</Target>

This section will contain the following four targets:

  • GenerateDDF
  • PackageWSP
  • DeploySolution
  • RetractSolution

The GenerateDDF target includes the tasks that create a Diamond Directive File (DDF) file. The PackageWSP target includes the tasks that create the .wsp file. The DeploySolution target includes the tasks that deploy the SharePoint solution for testing. The RetractSolution target includes the tasks that retract the SharePoint solution after testing.

Creating the GenerateDDF Target

The following code shows the GenerateDDF target.

<Target Name="GenerateDDF">
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Generating DDF..." Status="Succeeded" />
    <Copy SourceFiles="@(AssembliesToPackage)" DestinationFiles="@(AssembliesToPackage ->'$(ProjectTargetDir)\TEMP\%(FileName)%(Extension)')" />
    <Copy SourceFiles="@(SolutionItemsToPackage)" DestinationFiles="@(SolutionItemsToPackage ->'$(ProjectTargetDir)\TEMP\%(RecursiveDir)%(FileName)%(Extension)')" />
    <Exec WorkingDirectory="$(DDFGeneratorDir)" Command="DDFGenerator.exe $(ProjectTargetDir)\TEMP"/>
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Generating DDF complete." Status="Succeeded" />
</Target>

This target performs the first step in the build process for a SharePoint solution. It creates a .ddf file. A .ddf file defines the artifacts to include in the CAB file. It is required by the MakeCab tool. The GenerateDDF target includes the following three tasks:

  1. Copy all the compiled assemblies to a temp folder. This step ensures that the WSP contains the most current code for the site definition. The temp folder is where you will run the MakeCab tool in the next target.
  2. Copy the contents of the solution folder to the temp folder.
  3. Use the DDFGenerator program to create a Diamond Directive File (DDF) file that is named Solution.ddf.

Creating the PackageWSP Target

The next target creates the WSP. The following code shows the PackageWSP target file.

<Target Name="PackageWSP" DependsOnTargets="GenerateDDF">
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Packaging WSP..." Status="Succeeded" />
    <Exec WorkingDirectory="$(ProjectTargetDir)\TEMP" Command="MAKECAB /F solution.ddf /D CabinetNameTemplate=$(WSPPackageName) /D DiskDirectory1=..\TEMP" />
    <Copy SourceFiles="$(ProjectTargetDir)\TEMP\$(WSPPackageName)" DestinationFolder="$(BinariesRoot)"/>
    <Copy SourceFiles="$(ProjectTargetDir)\setup.bat" DestinationFolder="$(BinariesRoot)"/>
    <RemoveDir Directories="$(ProjectTargetDir)\TEMP" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Packaging WSP complete." Status="Succeeded" />
</Target>

The first task calls the MakeCab tool to generate the WSP. The Solution.ddf file that is generated by the GenerateDDF target instructs the MakeCab tool. After the WSP is created, the target copies it and the Setup.bat file that the extensions generated when you executed the Deploy Solution command to the BinariesRoot folder.

Creating the DeploySolution Target

After the WSP exists, you can deploy it and the other required files to the test environment. The following code shows the DeploySolution target.

<Target Name="DeploySolution" DependsOnTargets="PackageWSP">
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Deploying Solution..." Status="Succeeded" />
    <Exec Command="&quot;$(BinariesRoot)\setup.bat&quot; /uninstall" IgnoreExitCode="false" />
    <Exec Command="&quot;$(BinariesRoot)\setup.bat&quot; /install /siteurl $(SharePointSiteUrl)" IgnoreExitCode="false" />
    <Exec Command="$(IISAppScript) /a %22$(SharePointTestAppPool)%22 /r" IgnoreExitCode="false" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Deploying Solution complete." Status="Succeeded" />
</Target>

The DeploySolution target executes Setup.bat /uninstall to first deactivate all of the SharePoint features in the SharePoint solution, uninstall the features, retract the WSP, and then remove the WSP. Next, it executes Setup.bat /install to deploy the WSP and the Setup.bat file. Finally, the target recycles the application pool of the SharePoint test Web application in Internet Information Services (IIS).

Note

If your SharePoint solution contains a site definition, you may need to add additional commands to the DeploySolution target to create a new site. Also, the Setup.bat file that is created by the extensions only activates site collection features. If your solution does not contain a site definition, you need to add additional commands to create a SharePoint site before running Setup.bat /install.

Creating the RetractSolution Target

After the tests run, you can retract the WSP. The following code shows the RetractSolution target.

<Target Name="RetractSolution">
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Retracting Solution..." Status="Succeeded" />
    <Exec Command="&quot;$(BinariesRoot)\setup.bat&quot; /uninstall" IgnoreExitCode="true" />
    <Exec Command="$(IISAppScript) /a %22$(SharePointTestAppPool)%22 /r" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Retracting Solution complete..." Status="Succeeded" />
</Target>

The RetractSolution target executes Setup.bat /uninstall to first deactivate all the SharePoint features in the SharePoint solution, uninstall all features, retract the WSP, and then remove the WSP. It then recycles the application pool of the SharePoint test Web Application in IIS.

Creating a TFSBuild.proj File

To create an automated build in Team Foundation Server, you must supply a build definition. A build definition can be created from the Build menu in Visual Studio. For instructions on creating a build definition, see How To: Create a Build Definition on MSDN. You must associate the new build definition with a Visual Studio solution (.sln file) that includes the extensions project that you are deploying. Creating the build definition generates a TFSBuild.proj file.

Importing the SharePoint.targets File

You can now import the SharePoint.targets file and call the custom targets from the build. To import the SharePoint.targets file, include the following line of code in the TFSBuild.proj file.

<Import Project="C:\BuildTargets\SharePoint.targets"/>

Overriding the SharePoint.targets Properties

You must override the properties in the SharePoint.targets file with the values that are correct for the target build and the test environment. The following code in the TFSBuild.proj file demonstrates this. Note that the property values are sample values. You must replace them with values that are appropriate to your situation.

<PropertyGroup>  
    <!-- Path to the DDFGenerator tool -->
    <DDFGeneratorDir>C:\BuildTools</DDFGeneratorDir>
    <!-- Indicate where the Project's bin\debug folder is. MUST BE OVERRIDEN IN TFSBuild.proj! 
         This must be the debug folder because that is where the VSeWSS solution folder is checked in -->
    <ProjectTargetDir>C:\ TFS\Trunk\Source\MySolution\MyProject\bin\Debug</ProjectTargetDir>
    <!-- Path to the solution folder in the project -->
    <VSeWSSSolutionDir>$(ProjectTargetDir)\solution</VSeWSSSolutionDir>
    <!-- Path of the bin\(debug|release) folder to locate all of the binaries -->
    <BuildBinariesDir>$(BinariesRoot)\Debug</BuildBinariesDir>
    <!-- The name of the WSP listed in the setup.bat file -->
    <WSPPackageName>MySolution.wsp</WSPPackageName>
    <!-- Location to copy the files after successful build/package/test -->
    <TestDropDir>C:\ManualTestingDrops</TestDropDir>
</PropertyGroup>

Calling the Targets

The final step is to call the targets with targets that are named AfterCompile and AfterTest. The following code in the TFSBuild.proj file demonstrates how to do this.

<Target Name="AfterCompile">
        <CallTarget Targets="GenerateDDF; PackageWSP; DeploySolution" RunEachTargetSeparately="true" ContinueOnError="false" />
</Target>

<Target Name="AfterTest">   
    <CallTarget Targets="RetractSolution; CopyDrop" RunEachTargetSeparately="true" ContinueOnError="false" />    
</Target>

The first three custom targets are executed in the AfterCompile target. They can also be called from other targets that occur after the AfterCompile target but before the test target. The last custom target is executed in the AfterTest target. There is an additional optional custom target named CopyDrop that copies the WSP and Setup.bat files to a file share. This is for manual testing.

Preparing a SharePoint Site

After the WSP is deployed, you can call additional commands and properties to create a new site and/or activate SharePoint features, depending on your SharePoint solution, to prepare for testing. You can use test lists or test containers to specify tests to be run against the SharePoint site. After the tests run, you should also add additional commands or targets to delete the site.

Examples

The following code shows examples of a SharePoint.targets file and a TFSBuild.proj file. These files are the basis of the code samples that are used in this topic.

An Example SharePoint.targets file

The following code is an example of a SharePoint.targets file.

<?xml version="1.0" encoding="utf-8"?>

<Project xmlns="https://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

  <PropertyGroup>
    <!-- Path to the DDFGenerator tool -->
    <DDFGeneratorDir></DDFGeneratorDir>
    <!-- Indicate where the Project's bin\debug folder is. MUST BE OVERRIDEN IN TFSBuild.proj! 
         This must be the debug folder because that is where the VSeWSS solution folder is checked in -->
    <ProjectTargetDir></ProjectTargetDir>
    <!-- Path to the solution folder in the project -->
    <VSeWSSSolutionDir>$(ProjectTargetDir)\solution</VSeWSSSolutionDir>
    <!-- Path of the bin\(debug|release) folder to locate all of the binaries -->
    <BuildBinariesDir>$(BinariesRoot)\Debug</BuildBinariesDir>
    <!-- The name of the WSP listed in the setup.bat file. 
         This property should be overriden in the TFSBuild.Proj file for a custom name -->
    <WSPPackageName></WSPPackageName>
    <!-- Location to copy the files after successful build/package/test -->
    <TestDropDir></TestDropDir>
    <!-- Path to the STSADM tool -->
    <StsAdmWorkingDir>%commonprogramfiles%\Microsoft Shared\web server extensions\12\bin</StsAdmWorkingDir>
    <!-- Path to the IISAPP.VBS file -->
    <IISAppScript>&quot;C:\WINDOWS\system32\iisapp.vbs&quot;</IISAppScript>
    <!-- Name of the application pool in IIS for the SharePoint test site -->
    <SharePointTestAppPool>SharePoint - 80</SharePointTestAppPool>
    <!-- The Site Template code name of the Site Definition to create a site off of -->
    <SharePointSiteTemplateName></SharePointSiteTemplateName>
    <!-- The Site Template code name of the Site Definition to create a site off of -->
    <SharePointSiteTitle>Home</SharePointSiteTitle>
    <!-- The siteUrl of the SharePoint site to deploy to-->
    <SharePointSiteUrl>https://localhost</SharePointSiteUrl>
    <!-- The relative webUrl of the SharePoint site to create and deploy to -->
    <SharePointWebUrl></SharePointWebUrl>
  </PropertyGroup>

  <ItemGroup>
    <!-- Collection of assemblies that are to be included in the WSP -->
    <AssembliesToPackage Include="$(BuildBinariesDir)\*.dll"/>
    <!-- Collection of files that are to be included in the WSP -->
    <SolutionItemsToPackage Include="$(VSeWSSSolutionDir)\**\*.*" />
  </ItemGroup>

  <!-- Generate our DDF file from our solution folder -->
  <Target Name="GenerateDDF">
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Generating DDF..." Status="Succeeded" />
    <Copy SourceFiles="@(AssembliesToPackage)" DestinationFiles="@(AssembliesToPackage ->'$(ProjectTargetDir)\TEMP\%(FileName)%(Extension)')" />
    <Copy SourceFiles="@(SolutionItemsToPackage)" DestinationFiles="@(SolutionItemsToPackage ->'$(ProjectTargetDir)\TEMP\%(RecursiveDir)%(FileName)%(Extension)')" />
    <Exec WorkingDirectory="$(DDFGeneratorDir)" Command="DDFGenerator.exe $(ProjectTargetDir)\TEMP"/>
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Generating DDF complete." Status="Succeeded" />
  </Target>

  <!-- After the DDF is generated, the WSP will be created -->
  <Target Name="PackageWSP" DependsOnTargets="GenerateDDF">
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Packaging WSP..." Status="Succeeded" />
    <Exec WorkingDirectory="$(ProjectTargetDir)\TEMP" Command="MAKECAB /F solution.ddf /D CabinetNameTemplate=$(WSPPackageName) /D DiskDirectory1=..\TEMP" />
    <Copy SourceFiles="$(ProjectTargetDir)\TEMP\$(WSPPackageName)" DestinationFolder="$(BinariesRoot)"/>
    <Copy SourceFiles="$(ProjectTargetDir)\setup.bat" DestinationFolder="$(BinariesRoot)"/>
    <RemoveDir Directories="$(ProjectTargetDir)\TEMP" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Packaging WSP complete." Status="Succeeded" />
  </Target>

  <!-- Once the WSP is created, deploy the WSP to SharePoint -->
  <Target Name="DeploySolution" DependsOnTargets="PackageWSP">
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Deploying Solution..." Status="Succeeded" />
    <Exec Command="&quot;$(BinariesRoot)\setup.bat&quot; /uninstall" IgnoreExitCode="false" />
    <Exec Command="&quot;$(BinariesRoot)\setup.bat&quot; /install /siteurl $(SharePointSiteUrl)" IgnoreExitCode="false" />
    <Exec Command="$(IISAppScript) /a %22$(SharePointTestAppPool)%22 /r" IgnoreExitCode="false" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Deploying Solution complete." Status="Succeeded" />
  </Target>

  <!-- Create the SharePoint site using a site template -->
  <Target Name="CreateWeb">
    <Exec Command="&quot;$(StsAdmWorkingDir)\stsadm.exe&quot; -o createweb -url $(SharePointSiteUrl)/$(SharePointWebUrl) -sitetemplate &quot;$(SharePointSiteTemplateName)&quot; -title &quot;$(SharePointSiteTitle)&quot;"/>
  </Target>

  <!-- Delete the SharePoint site -->
  <Target Name="DeleteWeb">
    <Exec Command="&quot;$(StsAdmWorkingDir)\stsadm.exe&quot; -o deleteweb -url $(SharePointSiteUrl)/$(SharePointWebUrl)" IgnoreExitCode="true" />
  </Target>

  <!-- Retract the WSP -->
  <Target Name="RetractSolution">
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Retracting Solution..." Status="Succeeded" />
    <Exec Command="&quot;$(BinariesRoot)\setup.bat&quot; /uninstall" IgnoreExitCode="true" />
    <Exec Command="$(IISAppScript) /a %22$(SharePointTestAppPool)%22 /r" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Retracting Solution complete..." Status="Succeeded" />
  </Target>

  <!-- Copy WSP and Setup.bat to drop folder -->
  <Target Name="CopyDrop">
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Copying drop..." Status="Succeeded" />
    <Copy SourceFiles="$(BinariesRoot)\$(WSPPackageName)" DestinationFolder="$(TestDropDir)\$(BuildNumber)" />
    <Copy SourceFiles="$(BinariesRoot)\setup.bat" DestinationFolder="$(TestDropDir)\$(BuildNumber)" />
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)" BuildUri="$(BuildUri)" Message="Copying drop complete..." Status="Succeeded" />
  </Target>

</Project>

An Example TFSBuild.proj File

The following code is an example of a TFSBuild file.

<?xml version="1.0" encoding="utf-8"?>
<!-- DO NOT EDIT the project element - the ToolsVersion specified here does not prevent the solutions 
     and projects in the SolutionToBuild item group from targeting other versions of the .NET framework. 
     -->
<Project DefaultTargets="DesktopBuild" xmlns="https://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

  <!-- Do not edit this -->
  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />
  <!-- Custom SharePoint Targets file for packaging and deployment -->
  <Import Project="C:\SharePointTargets\SharePoint.targets"/>

  <ProjectExtensions>
    <!-- Team Foundation Build Version - DO NOT CHANGE -->
    <ProjectFileVersion>2</ProjectFileVersion>
    <!--  DESCRIPTION
     This property is included only for backwards compatibility. The description of a build definition 
     is now stored in the database. For compatibility with V1 clients, keep this property in sync with 
     the value in the database.
    -->
    <Description>This build is for testing the automated build/package/deploy/test how to.</Description>
    <!--  BUILD MACHINE
     This property is included only for backwards compatibility. The default machine used for a build 
     definition is now stored in the database, as the MachineName property of the definition's 
     DefaultBuildAgent. For compatibility with V1 clients, keep this property in sync with the value 
     in the database.
    -->
    <BuildMachine>spg-2k3-04</BuildMachine>
  </ProjectExtensions>

  <PropertyGroup>
    <!--  TEAM PROJECT
     This property is included only for backwards compatibility. The team project for a build 
     definition is now stored in the database. For compatibility with V1 clients, keep this property in 
     sync with the value in the database.
    -->
    <TeamProject>SPG</TeamProject>
    <!--  BUILD DIRECTORY
     This property is included only for backwards compatibility. The build directory used for a build 
     definition is now stored in the database, as the BuildDirectory property of the definition's 
     DefaultBuildAgent. For compatibility with V1 clients, keep this property in sync with the value 
     in the database.
    -->
    <BuildDirectoryPath>C:\SPGBuildDirectory</BuildDirectoryPath>
    <!--  DROP LOCATION
     This property is included only for backwards compatibility. The drop location used for a build 
     definition is now stored in the database. For compatibility with V1 clients, keep this property 
     in sync with the value in the database.
    -->
    <DropLocation>\\spg-2k3-04\BuildStageFolder</DropLocation>
    <!--  TESTING
     Set this flag to enable/disable running tests as a post-compilation build step.
    -->
    <RunTest>true</RunTest>
    <!--  CODE ANALYSIS
     Set this property to enable/disable running code analysis. Valid values for this property are 
     Default, Always and Never.

         Default - Perform code analysis as per the individual project settings
         Always  - Always perform code analysis irrespective of project settings
         Never   - Never perform code analysis irrespective of project settings
     -->
    <RunCodeAnalysis>Always</RunCodeAnalysis>
    <!-- Additional Properties -->
    <SkipWorkItemCreation>true</SkipWorkItemCreation>
    <UpdateAssociatedWorkItemsOnBuildBreak>false</UpdateAssociatedWorkItemsOnBuildBreak>
    <!--  WorkItemType
     The type of the work item created on a build failure. 
     -->
    <!--
    <WorkItemType>Bug</WorkItemType>
     -->
    <!--  WorkItemFieldValues
     Fields and values of the work item created on a build failure.

     Note: Use reference names for fields if you want the build to be resistant to field name 
     changes. Reference names are language independent while friendly names are changed depending 
     on the installed language. For example, "System.Reason" is the reference name for the "Reason" 
     field.
     -->
    <!--
    <WorkItemFieldValues>System.Reason=Build Failure;System.Description=Start the build using Team Build</WorkItemFieldValues>
     -->
    <!--  WorkItemTitle
     Title of the work item created on build failure.
     -->
    <!--
    <WorkItemTitle>Build failure in build:</WorkItemTitle>
     -->
    <!--  DescriptionText
     History comment of the work item created on a build failure. 
     -->
    <!--
    <DescriptionText>This work item was created by Team Build on a build failure.</DescriptionText>
     -->
    <!--  BuildLogText
     Additional comment text for the work item created on a build failure.
     -->
    <BuildlogText>The build log file is at:</BuildlogText>
    <!--  ErrorWarningLogText
     Additional comment text for the work item created on a build failure. 
     This text will only be added if there were errors or warnings.
     -->
    <ErrorWarningLogText>The errors/warnings log file is at:</ErrorWarningLogText>
    <!--  UpdateAssociatedWorkItems
     Set this flag to enable/disable updating associated workitems on a successful build.
     -->
    <UpdateAssociatedWorkItems>false</UpdateAssociatedWorkItems>
    <!--  AdditionalVCOverrides
     Additional text for the VCOverrides file generated for VC++ projects.
     -->
    <AdditionalVCOverrides></AdditionalVCOverrides>
    <!--  CustomPropertiesForClean
     Custom properties to pass to the MSBuild task while calling the "Clean" target for all solutions.
     The format should be: PropertyName1=value1;PropertyName2=value2;...
     -->
    <CustomPropertiesForClean></CustomPropertiesForClean>
    <!--  CustomPropertiesForBuild
     Custom properties to pass to the MSBuild task while calling the default targets for all solutions.
     The format should be: Property1=value1;Property2=value2;...  To pass custom properties to
     individual solutions, use the Properties metadata item of the SolutionToBuild ItemGroup.
     -->
    <CustomPropertiesForBuild></CustomPropertiesForBuild>
  </PropertyGroup>

  <ItemGroup>
    <!--  SOLUTIONS
     The paths of the solutions to build. Paths can be server paths or local paths, but server paths
     relative to the location of this file are highly recommended.  To add/delete solutions, edit this 
     ItemGroup. For example, to add a solution MySolution.sln, add the following line:

         <SolutionToBuild Include="$(BuildProjectFolderPath)/path/MySolution.sln" />

     To change the order in which the solutions are built, modify the order in which the solutions 
     appear below.

     To call a target (or targets) other than the default, add a metadata item named Targets.  To pass 
     custom properties to the solution, add a metadata item named Properties.  For example, to call 
     the targets MyCustomTarget1 and MyCustomTarget2, passing in properties Property1 and Property2, 
     add the following:

         <SolutionToBuild Include="$(BuildProjectFolderPath)/path/MySolution.sln">
             <Targets>MyCustomTarget1;MyCustomTarget2</Targets>
             <Properties>Property1=Value1;Property2=Value2</Properties>
         </SolutionToBuild>
    -->
    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../../Source/Contoso.RI.UpdateTheme/Contoso.RI.UpdateTheme.sln">
        <Targets></Targets>
        <Properties></Properties>
    </SolutionToBuild>
    <SolutionToBuild Include="$(BuildProjectFolderPath)/../../../Test/Contoso.RI.UpdateTheme.Tests/Contoso.RI.UpdateTheme.Tests.sln">
      <Targets></Targets>
      <Properties></Properties>
    </SolutionToBuild>
  </ItemGroup>

  <ItemGroup>
    <!--  CONFIGURATIONS
     The list of configurations to build. To add/delete configurations, edit this value. For example, 
     to add a new configuration, add the following lines:

         <ConfigurationToBuild Include="Debug|x86">
             <FlavorToBuild>Debug</FlavorToBuild>
             <PlatformToBuild>x86</PlatformToBuild>
         </ConfigurationToBuild>

     The Include attribute value should be unique for each ConfigurationToBuild node.
    -->
    <ConfigurationToBuild Include="Debug|Any CPU">
        <FlavorToBuild>Debug</FlavorToBuild>
        <PlatformToBuild>Any CPU</PlatformToBuild>
    </ConfigurationToBuild>
  </ItemGroup>

  <ItemGroup>
    <!--  TEST ARGUMENTS
     If the RunTest property is set to true then the following test arguments will be used to run 
     tests. Tests can be run by specifying one or more test lists and/or one or more test containers.

     To run tests using test lists, add MetaDataFile items and associated TestLists here.  Paths can 
     be server paths or local paths, but server paths relative to the location of this file are highly 
     recommended:

        <MetaDataFile Include="$(BuildProjectFolderPath)/HelloWorld/HelloWorld.vsmdi">
            <TestList>BVT1;BVT2</TestList>
        </MetaDataFile>

     To run tests using test containers, add TestContainer items here:

        <TestContainer Include="$(OutDir)\HelloWorldTests.dll" />
        <TestContainer Include="$(SolutionRoot)\TestProject\WebTest1.webtest" />
        <TestContainer Include="$(SolutionRoot)\TestProject\LoadTest1.loadtest" />

     Use %2a instead of * and %3f instead of ? to prevent expansion before test assemblies are built
    -->

      <MetaDataFile Include="$(BuildProjectFolderPath)/../../../Test/Contoso.RI.UpdateTheme.Tests/Contoso.RI.UpdateTheme.Tests.vsmdi">
          <TestList>Contoso.RI.UpdateTheme.Tests List</TestList>
      </MetaDataFile>
  </ItemGroup>

  <PropertyGroup>
    <!-- Path to the DDFGenerator tool -->
    <DDFGeneratorDir>C:\BVT\SharePointTargets</DDFGeneratorDir>
    <!-- Indicate where the Project's bin\debug folder is. MUST BE OVERRIDEN IN TFSBuild.proj! 
         This must be the debug folder because that is where the VSeWSS solution folder is checked in -->
    <ProjectTargetDir>C:\BVT\TFS\Trunk\Source\Contoso.RI.UpdateTheme\Contoso.RI.UpdateTheme\bin\Debug</ProjectTargetDir>
    <!-- Path to the solution folder in the project -->
    <VSeWSSSolutionDir>$(ProjectTargetDir)\solution</VSeWSSSolutionDir>
    <!-- Path of the bin\(debug|release) folder to locate all of the binaries -->
    <BuildBinariesDir>$(BinariesRoot)\Debug</BuildBinariesDir>
    <!-- The name of the WSP listed in the setup.bat file -->
    <WSPPackageName>ContosoTheme.wsp</WSPPackageName>
    <!-- Location to copy the files after successful build/package/test -->
    <TestDropDir>C:\BVT\Drops</TestDropDir>    
  </PropertyGroup>

  <Target Name="AfterCompile">
    <CallTarget Targets="GenerateDDF; PackageWSP; DeploySolution" RunEachTargetSeparately="true" ContinueOnError="false" />
  </Target>

  <Target Name="AfterTest">   
    <CallTarget Targets="RetractSolution; CopyDrop" RunEachTargetSeparately="true" ContinueOnError="false" />    
  </Target>
</Project>
Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Footer image

To provide feedback, get assistance, or download additional, please visit the SharePoint Guidance Community Web site.

Copyright © 2008 by Microsoft Corporation. All rights reserved.