2009-07-03 11 views
4

Ich versuche, einen TFS-Build einzurichten, und habe Probleme beim Abrufen meiner Tests als Teil des Builds. Ich erhalte die folgende seltsame Fehlermeldung im Buildprotokoll:TFS-Build: Fehler beim Ausführen von Tests

D:\TeamBuild\main-production\Company-Test DEV\Sources\root\main-production\customer-projects\Company\sc6-v2\Company-DEV.vsmdi 
    The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters. 
MSBUILD : warning MSB6006: "MSTest.exe" exited with code 1. 
    The previous error was converted to a warning because the task was called with ContinueOnError=true. 
    Build continuing because "ContinueOnError" on the task "TestToolsTask" is set to "true". 

Im Grunde ist es beschwert sich, dass der Weg zu meinem .vsmdi zu lang ist. Aber es ist nicht, es ist nur etwa 150 Zeichen, wenn das Limit 260 Zeichen angegeben wird.

Wie kann ich das beheben? Hier

ist die Datei 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>Master build for CUSTOMER</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>v-tfserver</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>webdanmark-production</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:\TeamBuild\</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>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>Never</RunCodeAnalysis> 

    <!-- Additional Properties --> 
     <TreatTestFailureAsBuildFailure>false</TreatTestFailureAsBuildFailure> 

    <!-- 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 CUSTOMERNAME:</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="$(BuildProjectFolderPath)/../../customer-projects/Customer/sc6-v2/CustomerName-DEV-v2.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: 


    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)/../../customer-projects/Customer/sc6-v2/Customer-DEV.vsmdi"> 
      <TestList>Customer;Tradelink;Webdanmark.Common</TestList> 
      <TestRunConfig>$(BuildProjectFolderPath)/../../customer-projects/Customer/codecoverage.testrunconfig</TestRunConfig> 
     </MetaDataFile> 

    </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> 
    --> 
     <TreatTestFailureAsBuildFailure>true</TreatTestFailureAsBuildFailure> 
    </PropertyGroup> 

    <ItemGroup> 
    <!-- ADDITIONAL REFERENCE PATH 
    The list of additional reference paths to use while resolving references. For example: 
    --> 
    <AdditionalReferencePath Include="D:\AdditionalReferences\Sitecore\6.0\rev090212" /> 
    <AdditionalReferencePath Include="D:\AdditionalReferences\Castle\net2.0-release-2007-9-20" /> 
    </ItemGroup> 
    <!-- "Publish" to Web server. --> 
    <PropertyGroup> 
     <PublishWebOutputTargetDir >\\test-Customer\Web\Sitecore\Customer\6.0\Website-v2\</PublishWebOutputTargetDir> 
    </PropertyGroup> 
    <ItemGroup> 
     <PublishedWebSource Include="$(BinariesRoot)\Release\_PublishedWebSites\Customer-Sitecore6-Dev-v2\**\*" Exclude="$(BinariesRoot)\Release\_PublishedWebSites\Customer-Sitecore6-Dev-v2\Web.confi*" /> 
     <PublishedWebConfig Include="$(BinariesRoot)\Release\_PublishedWebSites\Customer-Sitecore6-Dev-v2\Web.config.gennemse" /> 
     <PublishedWebConfigTarget Include="$(PublishWebOutputTargetDir)Web.config" /> 
    </ItemGroup> 
    <Target Name="AfterDropBuild" DependsOnTargets="publishWeb" /> 
    <Target Name="publishWeb" > 
     <Message Text="Starting publish to web server (from $(BinariesRoot)Release\_PublishedWebSites))" Importance="normal" /> 
     <Copy SourceFiles="@(PublishedWebSource)" DestinationFolder="$(PublishWebOutputTargetDir)%(RecursiveDir)" SkipUnchangedFiles="true" /> 
     <Copy SourceFiles="@(PublishedWebConfig)" DestinationFiles="@(PublishedWebConfigTarget)" /> 
     <Message Text="Publish OK." Importance="normal" /> 
    </Target> 
</Project> 
+0

Können Sie Ihre MSBUILD-Datei anzeigen? –

+0

Ja, ich habe es in der Frage hinzugefügt (SO sollte wirklich eine Anhangsfunktion haben). Soweit ich weiß, sollte es eine ziemlich standardisierte Konfiguration sein. – driis

Antwort

0

Ich habe dieses Problem schon früher, obwohl während des Aufbaus und nicht automatisierte Testausführung. Mein Problem war das TFS-Build-Arbeitsverzeichnis, in dem das Gerüst meines Projekts für den Build-Prozess neu erstellt wurde als Standard "$ (Temp) \ $ (BuildDefinitionPath)" belassen wurde. Ich habe das gelöst, indem ich es auf "d: \ build" verschoben habe.

Anweisungen hierzu können found here sein.

Verwandte Themen