locked
Task "GetBuildProperties" error MSB4131 RRS feed

  • Question

  • how about below error log?

    Build started 2008-12-29 11:00:53.
    Project "D:\TFS Team Build\WPFIntegration\BuildType\TFSBuild.proj" on node 0 (EndToEndIteration target(s)).
    Building with tools version "3.5".
    Target "CheckSettingsForEndToEndIteration" in file "C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" from project "D:\TFS Team Build\WPFIntegration\BuildType\TFSBuild.proj":
    Task "Error" skipped, due to false condition; ( '$(BuildDefinition)'=='' ) was evaluated as ( 'WPFBuild'=='' ).
    Task "Error" skipped, due to false condition; ( '$(BuildDefinitionId)'=='' ) was evaluated as ( '5'=='' ).
    Task "Error" skipped, due to false condition; ( '$(BuildUri)'=='' ) was evaluated as ( 'vstfs:///Build/Build/130'=='' ).
    Task "Error" skipped, due to false condition; ( '$(COMPUTERNAME)'=='' ) was evaluated as ( 'AHIT-VSTF'=='' ).
    Task "Error" skipped, due to false condition; ( '$(TeamFoundationServerUrl)'=='' ) was evaluated as ( 'http://ahit-vstf:8080/'=='' ).
    Task "Error" skipped, due to false condition; ( '$(TeamProject)'=='' ) was evaluated as ( 'AHIT'=='' ).
    Using "Message" task from assembly "Microsoft.Build.Tasks.v3.5, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
    Task "Message"
      BuildDefinition=WPFBuild
    Done executing task "Message".
    Task "Message"
      BuildDefinitionId=5
    Done executing task "Message".
    Task "Message"
      BuildUri=vstfs:///Build/Build/130
    Done executing task "Message".
    Task "Message"
      ComputerName=AHIT-VSTF
    Done executing task "Message".
    Task "Message"
      TeamFoundationServerUrl=http://ahit-vstf:8080/
    Done executing task "Message".
    Task "Message"
      TeamProject=AHIT
    Done executing task "Message".
    Done building target "CheckSettingsForEndToEndIteration" in project "TFSBuild.proj".
    Target "InitializeBuildProperties" in file "C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" from project "D:\TFS Team Build\WPFIntegration\BuildType\TFSBuild.proj":
    Using "GetBuildProperties" task from assembly "c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\Microsoft.TeamFoundation.Build.Tasks.dll".
    Task "GetBuildProperties"
      GetBuildProperties TeamFoundationServerUrl="http://ahit-vstf:8080/" BuildUri="vstfs:///Build/Build/130"
    C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(300,15): error MSB4131: The "Reason" parameter is not supported by the "GetBuildProperties" task. Verify the parameter exists on the task, and it is a gettable public instance property.
    Done executing task "GetBuildProperties".
    Done building target "InitializeBuildProperties" in project "TFSBuild.proj" -- FAILED.
    Done Building Project "D:\TFS Team Build\WPFIntegration\BuildType\TFSBuild.proj" (EndToEndIteration target(s)) -- FAILED.

    Build FAILED.

    "D:\TFS Team Build\WPFIntegration\BuildType\TFSBuild.proj" (EndToEndIteration target) (1) ->
    (InitializeBuildProperties target) ->
      C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(300,15): error MSB4131: The "Reason" parameter is not supported by the "GetBuildProperties" task. Verify the parameter exists on the task, and it is a gettable public instance property.

        0 Warning(s)
        1 Error(s)

    Time Elapsed 00:00:00.06

    Monday, December 29, 2008 3:04 AM

Answers

  • Hi,

    According to the MSDN documentation, the GetBuildProperties task doesn't contain a Reason property.  Here's the link.
    http://msdn.microsoft.com/en-us/library/bb399152.aspx

    If you could include your TFSBuild.proj, I might be able to help a little more.

    I hope this helps.

    Mike

    • Marked as answer by Hua Chen Wednesday, January 7, 2009 6:31 AM
    Monday, December 29, 2008 3:35 AM

All replies

  • Hi,

    According to the MSDN documentation, the GetBuildProperties task doesn't contain a Reason property.  Here's the link.
    http://msdn.microsoft.com/en-us/library/bb399152.aspx

    If you could include your TFSBuild.proj, I might be able to help a little more.

    I hope this helps.

    Mike

    • Marked as answer by Hua Chen Wednesday, January 7, 2009 6:31 AM
    Monday, December 29, 2008 3:35 AM
  • tks reply,here is my TFSBuild.proj

    <?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>10.100.0.218</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>AHIT</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>D:\TFS Team Build\WPFIntegration</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>\\10.100.0.218\public</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 Error;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>

      <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="D:\TFS Team Build\WPFIntegration\AHIT.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|Mixed Platforms">
            <FlavorToBuild>Release</FlavorToBuild>
            <PlatformToBuild>Mixed Platforms</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>
    </Project>

    Monday, December 29, 2008 3:50 AM
  • Hi,

    Are you using Scrum for TFS?  I found this workaround to change the following.

    <WorkItemFieldValues>System.Reason=Build Failure;System.Description=Start the build using Team Build</WorkItemFieldValues>

    To

    <WorkItemFieldValues>System.Description=Start the build using Team Build</WorkItemFieldValues>


    http://scrumforteamsystem.com/cs/forums/1497/ShowPost.aspx


    I hope this helps.

    Mike
    Monday, December 29, 2008 4:34 AM
  • MikeDouglas said:

    Hi,

    Are you using Scrum for TFS?  I found this workaround to change the following.

    <WorkItemFieldValues>System.Reason=Build Failure;System.Description=Start the build using Team Build</WorkItemFieldValues>

    To

    <WorkItemFieldValues>System.Description=Start the build using Team Build</WorkItemFieldValues>


    http://scrumforteamsystem.com/cs/forums/1497/ShowPost.aspx


    I hope this helps.

    Mike



    :( the same error log as bofore
    Monday, December 29, 2008 5:44 AM
  • What process template are you using? Agile? Scrum? custom?  I'm going to try to reproduce the error.

    Mike
    Wednesday, December 31, 2008 3:39 AM
  •  Hi,

    I got exactly the same problem today.
    I tried to change my TFSBuild.proj but it did not work, the same error around "Reason" field was encoutered.

    But, In fact, I understood the problem came from the targets file used to build which was the source with the error message
    "C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets(300,15): error MSB4131: The "Reason" parameter is not supported by the "GetBuildProperties" task. Verify the parameter exists on the task, and it is a gettable public instance property.
    "
    So,
    • I opened to the directory C:\Program Files\MSBuild\Microsoft\VisualStudio\TeamBuild\
    • I made a copy of the file Microsoft.TeamFoundation.Build.targets
    • I deleted into the original file the line which caused the problem  (search the word "Reason")            
      <Output TaskParameter="Reason" PropertyName="Reason" />
    • And finally, I saved the original file

    The new queued build was a success.

    I also try to build wrong code to have a real build failed and it was also working creating the BUG work item with Reason field.

    Hope this will help you ...

    Seeb

    • Proposed as answer by DaveIII Thursday, May 6, 2010 12:19 AM
    Wednesday, February 11, 2009 1:26 PM
  • Same problem, the problem appears after installing the Visual Studio 2008 SDK 1.1 package.
    Wednesday, April 1, 2009 9:20 AM
  • Hi all

    I've just updated a couple of TFS 2008 build servers to cater for VS2010 (by installing VS2010 on the build servers)...

    One worked ok, but the other failed with the same error as mentioned above.

    After some investigation on both build servers, I've found the following version differences of the assembly that contains the offending task (Microsoft.TeamFoundation.Build.Tasks.dll - within ...\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies)

    • The one that works uses version: 9.0.21022.8
    • The one that does not work uses version: 9.0.30729.1

    This indicates that a service pack or slightly different version of VS2008 or TFS build supports the Reason parameter while the older version does not.

    Trying to identify the differences between servers (to see what the working one has installed that the other doesn't) I found:

    The working server has:

    • Microsoft Windows SDK for Visual Studio 2008 SP1 Tools
    • Microsoft Windows SDK for Visual Studio 2008 SP1 Win32 Tools
    • Visual Studio version 9.0.30729.1 SP
    • TFS 2008 Build SP1

    The non-working server has:

    • Microsoft Windows SDK for Visual Studio 2008 Tools
    • Microsoft Windows SDK for Visual Studio 2008 Win32 Tools
    • Visual Studio version 9.0.21022.8 RTM
    • TFS 2008 Build RTM

    Looks like the working server has had the SP's applied and the non-working server only has the RTM (non SP'ed) versions.

    I'll try installing the SP on the faulty server.

    Update (4 Feb 2011): Updating the non-working server with VS2008 SP1 alone did not resolve the problem, but once TFS 2008 SP1 was installed, this fixed the problem (as it's the TFS 2008 SP1 that updated Microsoft.TeamFoundation.Build.Tasks.dll).  I would guess that VS2008 SP1 is not really required to resolve this issue, however, it's better practice to be running the latest SP's, and in my case, to keep all our TFS servers aligned - running the same versions of everything).

    HTH

    Tim


    • Edited by Tim Huffam Thursday, February 3, 2011 8:28 PM Updated to include resolution
    • Proposed as answer by Tim Huffam Thursday, February 3, 2011 8:29 PM
    Thursday, January 27, 2011 3:30 AM
  • This worked for me

     

    Team Build 2008 uses a build service that default is installed to the: %Program Files%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies folder. In this folder you can find the service configuration file: TFSBuildService.exe.config. This file is just a .NET application configuration file and contains several keys that can be set to tweak the Team Build 2008 build service.
    One of those keys is the MSBuildPath key. This key (if set) is used by the service to locate MSBuild.exe and use that version of MSBuild to execute the build process.
    So by setting the MSBuildPath key to the .NET 4.0 folder (default: %WINDOWS%\Microsoft.NET\ Framework\v4.0.30319), we can configure the build service to use MSBuild 4.0.
    After updating the configuration file just restart the Visual Studio Team Foundation Build service and your good to go!

     

    Source: http://blogs.infosupport.com/blogs/martijnb/archive/2010/05/04/building-visual-studio-2010-solutions-using-team-build-2008.aspx

     

    Hope it helps!

    Sunday, February 27, 2011 6:46 PM