Ask a questionAsk a question
 

AnswerCheck-out files during build

  • Wednesday, November 04, 2009 1:09 PMamir tohidi Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi

    I am trying to use the TFSBuild.proj example documented in this blog entry by Gautam Goenka here: http://blogs.msdn.com/gautamg/archive/2006/01/04/509146.aspx

    I have installed the required MSBuild Extension pack and I am trying to use the MSBuild.ExtensionPack.VersionNumber.targets to get Team Build to update the AssemblyInfo.cs files. Unfortunately, I am getting the following error on the checkout part:

    error MSB3073: The command ""D:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\..\tf.exe" checkout /recursive AssemblyInfo.cs" exited with code 1.

    It appears that the files' full path is needed. But when I hard coded the path into the build definition I got another saying that the Workspace does not exist! Also, AssemblyInfoFiles his defined but not used - so I tried to use that instead of  
    AssemblyInfoSpec and still did not get anywhere.

    I have spent three days on this (my first time with Team Build and MSBuild) and I am not getting anywhere. Can anyone spot what I am doing wrong please?


    My TFSBuild.proj looks like (showing relevant bits only):

    <

     

    Import Project="C:\Program Files\MSBuild\ExtensionPack\MSBuild.ExtensionPack.VersionNumber.targets" />


    <

     

    PropertyGroup>
       <!--
    Assembly version properties. Add others here -->
       <
    AssemblyMajorVersion>9</AssemblyMajorVersion>
       <
    AssemblyFileMajorVersion>9</AssemblyFileMajorVersion>

       <!--

     

    TF.exe -->
       <
    TF>&quot;$(TeamBuildRefPath)\..\tf.exe&quot;</TF>

       <!--

     

    AssemblyInfo file spec -->
       <
    AssemblyInfoSpec>AssemblyInfo.cs</AssemblyInfoSpec>

    </
    PropertyGroup>

    <!--

     

    Set this to non-existent file to force rebuild. -->
    <
    ItemGroup>
       <
    IntermediateAssembly Include="$(SolutionRoot)\foobar.dll"/>
    </
    ItemGroup>




    <

     

    Target Name="AfterGet" Condition="'$(IsDesktopBuild)'!='true'">
        <!--
    Set the AssemblyInfoFiles items dynamically -->
        <
    CreateItem Include="$(SolutionRoot)\**\$(AssemblyInfoSpec)">
             <
    Output ItemName="AssemblyInfoFiles" TaskParameter="Include" />
        </
    CreateItem>

        <

     

    Message Text="AssemblyInfoSpec = $(AssemblyInfoSpec)" />

        <

     

    Exec WorkingDirectory="$(SolutionRoot)"
          Command="$(TF) checkout /recursive $(AssemblyInfoSpec)"/>
    </
    Target>

    <

     

    Target Name="AfterCompile" Condition="'$(IsDesktopBuild)'!='true'">
        <
    Exec WorkingDirectory="$(SolutionRoot)"
        Command="$(TF) checkin /comment:&quot;Auto-Build: Version Update&quot; /noprompt /override:&quot;Auto-Build: Version Update&quot; /recursive $(AssemblyInfoSpec)"/>
    </
    Target>

    <!--

     

    In case of Build failure, the AfterCompile target is not executed. Undo the changes -->

    <

     

    Target Name="BeforeOnBuildBreak" Condition="'$(IsDesktopBuild)'!='true'">
        <
    Exec WorkingDirectory="$(SolutionRoot)"
          Command="$(TF) undo /noprompt /recursive $(AssemblyInfoSpec)"/>
    </
    Target>

     

Answers

  • Thursday, November 05, 2009 9:41 AMamir tohidi Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    I found the cause of the problem: our team project is called "TFS Implementation" - it has a space in it. So, I had to wrap @(AssemblyInfoSpec) with quotes using &quot;@(AssemblyInfoFiles)&quot;

    Big thanks to Ewald for putting me on the right path. I'd buy you a drink Ewald if you were in England.

    I have spent almost a week to get to this point. Every sample that I tried had a bug in it (which is why Ewald post was important). Below is the complete build definition that now works:

    Pasting from Notepad as the Visual Studio copy messes up the formatting:

    <?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="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

      <!-- Do not edit this -->
      <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.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></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>entaap615d</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>TFS Implementation</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>E:\TFB\Build\TFS Implementation\AutomatedBuilds2</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>\\UNKNOWN\drops</DropLocation>

        <!--  TESTING
         Set this flag to enable/disable running tests as a post-compilation build step.
        -->
        <RunTest>false</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>Never</RunCodeAnalysis>

        <!-- Additional Properties -->

        <!--  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>true</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>

      <!--<AIT>-->
      <PropertyGroup>
        <!-- Assembly version properties. Add others here -->
        <AssemblyMajorVersion>9</AssemblyMajorVersion>
        <AssemblyFileMajorVersion>9</AssemblyFileMajorVersion>

        <!-- TF.exe -->
        <TF>&quot;$(TeamBuildRefPath)\..\tf.exe&quot;</TF>

        <!-- AssemblyInfo file spec -->
        <AssemblyInfoSpec>AssemblyInfo.cs</AssemblyInfoSpec>
      </PropertyGroup>

      <!-- Set this to non-existent file to force rebuild. -->
      <ItemGroup>
        <IntermediateAssembly Include="$(SolutionRoot)\foobar.dll"/>
      </ItemGroup>
      <!--</AIT>-->

      <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)/../../Main/Src/TfbAutomatedBuilds/AutomatedBuilds.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="Release|Any CPU">
            <FlavorToBuild>Release</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
        -->

      </ItemGroup>

      <PropertyGroup>
        <!-- TEST ARGUMENTS
         If the RunTest property is set to true, then particular tests within a
         metadata file or test container may be specified here.  This is
         equivalent to the /test switch on mstest.exe.

         <TestNames>BVT;HighPriority</TestNames>
        -->

      </PropertyGroup>

      <ItemGroup>
        <!--  ADDITIONAL REFERENCE PATH
         The list of additional reference paths to use while resolving references. For example:
        
             <AdditionalReferencePath Include="C:\MyFolder\" />
             <AdditionalReferencePath Include="C:\MyFolder2\" />
        -->
      </ItemGroup>

      <!--<AIT>-->
      <Target Name="AfterGet" Condition="'$(IsDesktopBuild)'!='true'">
       
        <!-- Set the AssemblyInfoFiles items dynamically -->
        <CreateItem Include="$(SolutionRoot)\**\$(AssemblyInfoSpec)">
          <Output ItemName="AssemblyInfoFiles" TaskParameter="Include" />
        </CreateItem>

        <Exec WorkingDirectory="$(SolutionRoot)"
              Command="$(TF) checkout /recursive &quot;@(AssemblyInfoFiles)&quot;"/>
      </Target>

      <Target Name="AfterCompile" Condition="'$(IsDesktopBuild)'!='true'">
        <Exec WorkingDirectory="$(SolutionRoot)"
              Command="$(TF) checkin /comment:&quot;Auto-Build: Version Update&quot; /noprompt /override:&quot;Auto-Build: Version Update&quot; /recursive &quot;@(AssemblyInfoFiles)&quot;" />
      </Target>
      <!-- In case of Build failure, the AfterCompile target is not executed. Undo the changes -->
      <Target Name="BeforeOnBuildBreak" Condition="'$(IsDesktopBuild)'!='true'">
        <Exec WorkingDirectory="$(SolutionRoot)"
              Command="$(TF) undo /noprompt /recursive &quot;@(AssemblyInfoFiles)&quot;" />
      </Target>
      <!--</AIT>-->

    </Project>

    • Marked As Answer byamir tohidi Thursday, November 05, 2009 10:15 AM
    •  

All Replies

  • Wednesday, November 04, 2009 8:00 PMEwald Hofman - Avanade Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    You must use @(AssemblyInfoSpec) I think, because it is an item and not a property. To be sure, you can add a <Message Text="$(AssemblyInfoSpec)" /> line to be sure.
    Ewald - Please remember to mark the replies as answers if they help.

    Ewald Hofman
    Blog: www.ewaldhofman.nl
  • Wednesday, November 04, 2009 8:01 PMrcatwork Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Did you use the TFS path to the file? "$/<source location>/AssemblyInfo.cs"? If you use the disk path, "c:\<path>\AssemblyInfo.cs", it will not work.
  • Wednesday, November 04, 2009 8:26 PMMike Fourie Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    No, $ is correct, it's a property. The dodgy formatting threw me too.

    Amir, the article that you refer to is good and i don't see anything obvious. I have done my utmost to steer away from using this method of versioning in TFS though. I would recommend using the TFSVersion task in the Extension Pack rather. I have some thoughts on versioning here and here which are a bit old, but should be worth a read.

    Mike
  • Thursday, November 05, 2009 8:59 AMamir tohidi Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     

    Hi Ewald

    Thanks. You were absolutely right - I changed to @(AssemblyInfoSpec) and manged to get further in the build.

    Unfortunately, I am now getting this error on checkout:

    Using "Exec" task from assembly "Microsoft.Build.Tasks.v3.5, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
    Task "Exec"
      Command:
      "D:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\..\tf.exe" checkout /recursive E:\TFB\Build\TFS Implementation\AutomatedBuilds2\Sources\Main\Src\TfbAutomatedBuilds\AutomatedBuilds\Properties\AssemblyInfo.cs
      No matching items found in E:\TFB\Build\TFS in your workspace.
      No matching items found in E:\TFB\Build\TFS Implementation\AutomatedBuilds2\Sources\Implementation\AutomatedBuilds2\Sources\Main\Src\TfbAutomatedBuilds\AutomatedBuilds\Properties\AssemblyInfo.cs in your workspace.
    E:\TFB\Build\TFS Implementation\AutomatedBuilds2\BuildType\TFSBuild.proj(259,5): error MSB3073: The command ""D:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\..\tf.exe" checkout /recursive E:\TFB\Build\TFS Implementation\AutomatedBuilds2\Sources\Main\Src\TfbAutomatedBuilds\AutomatedBuilds\Properties\AssemblyInfo.cs" exited with code 1.
    Done executing task "Exec" -- FAILED.

    The problem seems to be that Team Build has created a workspace but the tf.exe checkout does not know where the workspace is. Looking at MSDN, there doesn't appear to be any way specifying the workspace in tf checkout



  • Thursday, November 05, 2009 9:41 AMamir tohidi Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer

    I found the cause of the problem: our team project is called "TFS Implementation" - it has a space in it. So, I had to wrap @(AssemblyInfoSpec) with quotes using &quot;@(AssemblyInfoFiles)&quot;

    Big thanks to Ewald for putting me on the right path. I'd buy you a drink Ewald if you were in England.

    I have spent almost a week to get to this point. Every sample that I tried had a bug in it (which is why Ewald post was important). Below is the complete build definition that now works:

    Pasting from Notepad as the Visual Studio copy messes up the formatting:

    <?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="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="3.5">

      <!-- Do not edit this -->
      <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.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></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>entaap615d</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>TFS Implementation</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>E:\TFB\Build\TFS Implementation\AutomatedBuilds2</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>\\UNKNOWN\drops</DropLocation>

        <!--  TESTING
         Set this flag to enable/disable running tests as a post-compilation build step.
        -->
        <RunTest>false</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>Never</RunCodeAnalysis>

        <!-- Additional Properties -->

        <!--  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>true</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>

      <!--<AIT>-->
      <PropertyGroup>
        <!-- Assembly version properties. Add others here -->
        <AssemblyMajorVersion>9</AssemblyMajorVersion>
        <AssemblyFileMajorVersion>9</AssemblyFileMajorVersion>

        <!-- TF.exe -->
        <TF>&quot;$(TeamBuildRefPath)\..\tf.exe&quot;</TF>

        <!-- AssemblyInfo file spec -->
        <AssemblyInfoSpec>AssemblyInfo.cs</AssemblyInfoSpec>
      </PropertyGroup>

      <!-- Set this to non-existent file to force rebuild. -->
      <ItemGroup>
        <IntermediateAssembly Include="$(SolutionRoot)\foobar.dll"/>
      </ItemGroup>
      <!--</AIT>-->

      <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)/../../Main/Src/TfbAutomatedBuilds/AutomatedBuilds.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="Release|Any CPU">
            <FlavorToBuild>Release</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
        -->

      </ItemGroup>

      <PropertyGroup>
        <!-- TEST ARGUMENTS
         If the RunTest property is set to true, then particular tests within a
         metadata file or test container may be specified here.  This is
         equivalent to the /test switch on mstest.exe.

         <TestNames>BVT;HighPriority</TestNames>
        -->

      </PropertyGroup>

      <ItemGroup>
        <!--  ADDITIONAL REFERENCE PATH
         The list of additional reference paths to use while resolving references. For example:
        
             <AdditionalReferencePath Include="C:\MyFolder\" />
             <AdditionalReferencePath Include="C:\MyFolder2\" />
        -->
      </ItemGroup>

      <!--<AIT>-->
      <Target Name="AfterGet" Condition="'$(IsDesktopBuild)'!='true'">
       
        <!-- Set the AssemblyInfoFiles items dynamically -->
        <CreateItem Include="$(SolutionRoot)\**\$(AssemblyInfoSpec)">
          <Output ItemName="AssemblyInfoFiles" TaskParameter="Include" />
        </CreateItem>

        <Exec WorkingDirectory="$(SolutionRoot)"
              Command="$(TF) checkout /recursive &quot;@(AssemblyInfoFiles)&quot;"/>
      </Target>

      <Target Name="AfterCompile" Condition="'$(IsDesktopBuild)'!='true'">
        <Exec WorkingDirectory="$(SolutionRoot)"
              Command="$(TF) checkin /comment:&quot;Auto-Build: Version Update&quot; /noprompt /override:&quot;Auto-Build: Version Update&quot; /recursive &quot;@(AssemblyInfoFiles)&quot;" />
      </Target>
      <!-- In case of Build failure, the AfterCompile target is not executed. Undo the changes -->
      <Target Name="BeforeOnBuildBreak" Condition="'$(IsDesktopBuild)'!='true'">
        <Exec WorkingDirectory="$(SolutionRoot)"
              Command="$(TF) undo /noprompt /recursive &quot;@(AssemblyInfoFiles)&quot;" />
      </Target>
      <!--</AIT>-->

    </Project>

    • Marked As Answer byamir tohidi Thursday, November 05, 2009 10:15 AM
    •  
  • Thursday, November 05, 2009 2:27 PMamir tohidi Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Mike

    Thanks for your message.

    I had already come across your articles but to be honest I did not fully understand the point being made. I have just got started with all of this Team Build / MSBuild stuff and my head is blowing up already.

    We need our version numbers to change when we do a Team Build because the build will contain new code. Being a revised code base, the version number needs to change so that we know what version of code we are sending to system test, UAT, or production.

    Am I missing something?
  • Thursday, November 05, 2009 4:18 PMMike Fourie Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi Amir

    All you are missing is a clear up to date blog post from me. It's been on my todo list for way too long... I'll try get something published soon.... Mike
  • Friday, November 06, 2009 1:41 PMamir tohidi Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Hi Mike

    Ok. I look forward to reading it.

    Thanks
    Amir