Team Build errors, after build of checkins w/ associated Task from another Team Project

When a Team build is run following checkin of changes with no associated Task, or the checkin is associated with a Task in the same Team Project as the build, the build will correctly get changesets and associated work items.

However, a Team build run following checkin of changes with association to a Task in a *different* Team Project, to that within which the Team Build resides, will produce the following error, and fail to associate the build with the changesets.

Has anyone else seen this error? Is there a workaround?

Here is the relevant section from the build log:

C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\TeamBuild\Microsoft.TeamFoundation.Build.targets : warning MSB4018: The "GenCheckinNotesUpdateWorkItems" task failed unexpectedly.

C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\TeamBuild\Microsoft.TeamFoundation.Build.targets : warning MSB4018: System.NullReferenceException: Object reference not set to an instance of an object.

C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\TeamBuild\Microsoft.TeamFoundation.Build.targets : warning MSB4018: at Microsoft.TeamFoundation.Build.Tasks.GenCheckinNotesUpdateWorkItems.DoUpdateWorkitems(Dictionary`2 changesets)

C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\TeamBuild\Microsoft.TeamFoundation.Build.targets : warning MSB4018: at Microsoft.TeamFoundation.Build.Tasks.GenCheckinNotesUpdateWorkItems.Execute()

C:\Program Files\MSBuild\Microsoft\VisualStudio\v8.0\TeamBuild\Microsoft.TeamFoundation.Build.targets : warning MSB4018: at Microsoft.Build.BuildEngine.TaskEngine.ExecuteTask(ExecutionMode howToExecuteTask, Hashtable projectItemsAvailableToTask, BuildPropertyGroup projectPropertiesAvailableToTask, Boolean& taskClassWasFound)

The previous error was converted to a warning because the task was called with ContinueOnError=true.

Build continuing because "ContinueOnError" on the task "GenCheckinNotesUpdateWorkItems" is set to "true".

[2033 byte] By [PeterHaynes] at [2007-12-17]
# 1

We are unable to repro this problem on our machines. A couple of questions:

1. What bits are you using Beta2 or Beta3?
2. Are both team projects using the same methodology?

Anutthara at 2007-9-9 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...
# 2

1. > Beta 3
2. > Both are CMMI.

PeterHaynes at 2007-9-9 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...
# 3
I am still unable to repro this bug on my machines. Would you please answer a few more qs for me?

1. Is this an upgrade from B2 or a fresh install of B3?
2. Would you post a TFSBuild.proj file from both team projects?

Our devs are investigating this issue. Thanks for your patience.

Anutthara at 2007-9-9 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...
# 4
Here is an update: the scenario you describe above where you associate a changeset of Team Project 1 with a task in Team Project 2 is not a supported scenario. We support association of tasks to changesets shown up in build only within a team project.

Would you please let me know why you are coming up with this particular requirement at all?

Anutthara at 2007-9-9 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...
# 5
First, thanks for looking into this.

The whole setup was a clean Beta 3, and not an upgrade.

This may be significant: Looking at the Task WorkItem, I've noticed that if I look at the Task details tab, and then view the list of Integration build choices, that the builds listed are 'restricted' to builds that have taken place *inside* that Team Project, and it does not list builds from any other Team Project. I wonder if the build fails (when checkin is against task from another Team Project) because in some way this 'restriction' observed at GUI level, is working in a similar way under the hood, to prevent the build updating the other Team Project's work item?

Here are the two TFSBuild.proj files.

TFSBuild.proj for the DEVELOPMENT Team Project:

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

<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<!-- TO EDIT BUILD TYPE DEFINITION

To edit the build type, you will need to edit this file which was generated

by the Create New Build Type wizard. This file is under source control and

needs to be checked out before making any changes.

The file is available at -

$/{TeamProjectName}/TeamBuildTypes/{BuildTypeName}

where you will need to replace TeamProjectName and BuildTypeName with your

Team Project and Build Type name that you created

Checkout the file

1. Open Source Control Explorer by selecting View -> Other Windows -> Source Control Explorer

2. Ensure that your current workspace has a mapping for the $/{TeamProjectName}/TeamBuildTypes folder and

that you have done a "Get Latest Version" on that folder

3. Browse through the folders to {TeamProjectName}->TeamBuildTypes->{BuildTypeName} folder

4. From the list of files available in this folder, right click on TfsBuild.Proj. Select 'Check Out For Edit...'

Make the required changes to the file and save

Checkin the file

1. Right click on the TfsBuild.Proj file selected in Step 3 above and select 'Checkin Pending Changes'

2. Use the pending checkin dialog to save your changes to the source control

Once the file is checked in with the modifications, all future builds using

this build type will use the modified settings

-->

<!-- Do not edit this -->

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\TeamBuild\Microsoft.TeamFoundation.Build.targets" />

<ProjectExtensions>

<!-- DESCRIPTION

The description is associated with a build type. Edit the value for making changes.

-->

<Description>

</Description>

<!-- BUILD MACHINE

Name of the machine which will be used to build the solutions selected.

-->

<BuildMachine>vsts-cm-06</BuildMachine>

</ProjectExtensions>

<PropertyGroup>

<!-- TEAM PROJECT

The team project which will be built using this build type.

-->

<TeamProject>DEVELOPMENT</TeamProject>

<!-- BUILD DIRECTORY

The directory on the build machine that will be used to build the

selected solutions. The directory must be a local path on the build

machine (e.g. c:\build).

-->

<BuildDirectoryPath>C:\Build</BuildDirectoryPath>

<!-- DROP LOCATION

The location to drop (copy) the built binaries and the log files after

the build is complete. This location has to be a valid UNC path of the

form \\Server\Share. The build machine service account and application

tier account need to have read write permission on this share.

-->

<DropLocation>\\vsts-cm-06\DEVELOPMENT_DROP</DropLocation>

<!-- TESTING

Set this flag to enable/disable running tests as a post build step.

-->

<RunTest>false</RunTest>

<!-- WorkItemFieldValues

Add/edit key value pairs to set values for fields in the work item created

during the build process. Please make sure the field names are valid

for the work item type being used.

-->

<WorkItemFieldValues>Priority=1;Severity=1</WorkItemFieldValues>

<!-- CODE ANALYSIS

To change CodeAnalysis behavior edit this value. Valid values for this

can be Default,Always or Never.

Default - To perform code analysis as per the individual project settings

Always - To always perform code analysis irrespective of project settings

Never - To never perform code analysis irrespective of project settings

-->

<RunCodeAnalysis>Never</RunCodeAnalysis>

<!-- UPDATE ASSOCIATED WORK ITEMS

Set this flag to enable/disable updating associated workitems on a successful build

-->

<UpdateAssociatedWorkItems>true</UpdateAssociatedWorkItems>

</PropertyGroup>

<ItemGroup>

<!-- SOLUTIONS

The path of the solutions to build. To add/delete solutions, edit this

value. For example, to add a solution MySolution.sln, add following line -

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

To change the order in which the solutions are build, modify the order in

which the solutions appear below.

-->

<SolutionToBuild Include="$(SolutionRoot)\Exweb\Code\Components\ExampleComponent02\ExampleComponent02.sln" />

<SolutionToBuild Include="$(SolutionRoot)\Exweb\Code\Webs\ExchangeDemoSite\ExchangeDemoSite.sln" />

</ItemGroup>

<ItemGroup>

<!-- CONFIGURATIONS

The list of configurations to build. To add/delete configurations, edit

this value. For example, to add a new configuration, add 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>

<ConfigurationToBuild Include="Debug|.NET">

<FlavorToBuild>Debug</FlavorToBuild>

<PlatformToBuild>.NET</PlatformToBuild>

</ConfigurationToBuild>

</ItemGroup>

<ItemGroup>

<!-- TEST ARGUMENTS

If the RunTest is set to true then the following test arguments will be

used to run tests.

To add/delete new testlist or to choose a metadata file (.vsmdi) file, edit this value.

For e.g. to run BVT1 and BVT2 type tests mentioned in the Helloworld.vsmdi file, add the following -

<MetaDataFile Include="$(SolutionRoot)\HelloWorld\HelloWorld.vsmdi">

<TestList>BVT1;BVT2</TestList>

</MetaDataFile>

Where BVT1 and BVT2 are valid test types defined in the HelloWorld.vsmdi file.

MetaDataFile - Full path to test metadata file.

TestList - The test list in the selected metadata file to run.

Please note that you need to specify the vsmdi file relative to $(SolutionRoot)

-->

<MetaDataFile Include=" ">

<TestList> </TestList>

</MetaDataFile>

</ItemGroup>

<ItemGroup>

<!-- ADDITIONAL REFERENCE PATH

The list of additional reference paths to use while resolving references.

For example,

<AdditionalReferencePath Include="C:\MyFolder\" />

-->

<AdditionalReferencePath Include="$(SolutionRoot)..\..\Components\Binaries" />

</ItemGroup>

</Project>
TFSBuild.proj for the CM_BASE Team Project:

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

<Project DefaultTargets="DesktopBuild" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<!-- TO EDIT BUILD TYPE DEFINITION

To edit the build type, you will need to edit this file which was generated

by the Create New Build Type wizard. This file is under source control and

needs to be checked out before making any changes.

The file is available at -

$/{TeamProjectName}/TeamBuildTypes/{BuildTypeName}

where you will need to replace TeamProjectName and BuildTypeName with your

Team Project and Build Type name that you created

Checkout the file

1. Open Source Control Explorer by selecting View -> Other Windows -> Source Control Explorer

2. Ensure that your current workspace has a mapping for the $/{TeamProjectName}/TeamBuildTypes folder and

that you have done a "Get Latest Version" on that folder

3. Browse through the folders to {TeamProjectName}->TeamBuildTypes->{BuildTypeName} folder

4. From the list of files available in this folder, right click on TfsBuild.Proj. Select 'Check Out For Edit...'

Make the required changes to the file and save

Checkin the file

1. Right click on the TfsBuild.Proj file selected in Step 3 above and select 'Checkin Pending Changes'

2. Use the pending checkin dialog to save your changes to the source control

Once the file is checked in with the modifications, all future builds using

this build type will use the modified settings

-->

<!-- Do not edit this -->

<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0\TeamBuild\Microsoft.TeamFoundation.Build.targets" />

<ProjectExtensions>

<!-- DESCRIPTION

The description is associated with a build type. Edit the value for making changes.

-->

<Description>

</Description>

<!-- BUILD MACHINE

Name of the machine which will be used to build the solutions selected.

-->

<BuildMachine>vsts-cm-06</BuildMachine>

</ProjectExtensions>

<PropertyGroup>

<!-- TEAM PROJECT

The team project which will be built using this build type.

-->

<TeamProject>CM_BASE</TeamProject>

<!-- BUILD DIRECTORY

The directory on the build machine that will be used to build the

selected solutions. The directory must be a local path on the build

machine (e.g. c:\build).

-->

<BuildDirectoryPath>C:\Build</BuildDirectoryPath>

<!-- DROP LOCATION

The location to drop (copy) the built binaries and the log files after

the build is complete. This location has to be a valid UNC path of the

form \\Server\Share. The build machine service account and application

tier account need to have read write permission on this share.

-->

<DropLocation>\\vsts-cm-06\CM_BASE_DROP</DropLocation>

<!-- TESTING

Set this flag to enable/disable running tests as a post build step.

-->

<RunTest>false</RunTest>

<!-- WorkItemFieldValues

Add/edit key value pairs to set values for fields in the work item created

during the build process. Please make sure the field names are valid

for the work item type being used.

-->

<WorkItemFieldValues>Priority=1;Severity=1</WorkItemFieldValues>

<!-- CODE ANALYSIS

To change CodeAnalysis behavior edit this value. Valid values for this

can be Default,Always or Never.

Default - To perform code analysis as per the individual project settings

Always - To always perform code analysis irrespective of project settings

Never - To never perform code analysis irrespective of project settings

-->

<RunCodeAnalysis>Never</RunCodeAnalysis>

<!-- UPDATE ASSOCIATED WORK ITEMS

Set this flag to enable/disable updating associated workitems on a successful build

-->

<UpdateAssociatedWorkItems>true</UpdateAssociatedWorkItems>

</PropertyGroup>

<ItemGroup>

<!-- SOLUTIONS

The path of the solutions to build. To add/delete solutions, edit this

value. For example, to add a solution MySolution.sln, add following line -

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

To change the order in which the solutions are build, modify the order in

which the solutions appear below.

-->

<SolutionToBuild Include="$(SolutionRoot)\Exweb\Code\Components\ExampleComponent02\ExampleComponent02.sln" />

<SolutionToBuild Include="$(SolutionRoot)\Exweb\Code\Webs\ExchangeDemoSite\ExchangeDemoSite.sln" />

</ItemGroup>

<ItemGroup>

<!-- CONFIGURATIONS

The list of configurations to build. To add/delete configurations, edit

this value. For example, to add a new configuration, add 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>

<ConfigurationToBuild Include="Debug|.NET">

<FlavorToBuild>Debug</FlavorToBuild>

<PlatformToBuild>.NET</PlatformToBuild>

</ConfigurationToBuild>

</ItemGroup>

<ItemGroup>

<!-- TEST ARGUMENTS

If the RunTest is set to true then the following test arguments will be

used to run tests.

To add/delete new testlist or to choose a metadata file (.vsmdi) file, edit this value.

For e.g. to run BVT1 and BVT2 type tests mentioned in the Helloworld.vsmdi file, add the following -

<MetaDataFile Include="$(SolutionRoot)\HelloWorld\HelloWorld.vsmdi">

<TestList>BVT1;BVT2</TestList>

</MetaDataFile>

Where BVT1 and BVT2 are valid test types defined in the HelloWorld.vsmdi file.

MetaDataFile - Full path to test metadata file.

TestList - The test list in the selected metadata file to run.

Please note that you need to specify the vsmdi file relative to $(SolutionRoot)

-->

<MetaDataFile Include=" ">

<TestList> </TestList>

</MetaDataFile>

</ItemGroup>

<ItemGroup>

<!-- ADDITIONAL REFERENCE PATH

The list of additional reference paths to use while resolving references.

For example,

<AdditionalReferencePath Include="C:\MyFolder\" />

-->

<AdditionalReferencePath Include="$(SolutionRoot)..\..\Components\Binaries" />

</ItemGroup>

</Project>

PeterHaynes at 2007-9-9 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...
# 6
Thank you Peter. The info you have mentioned above might be the reason for the failure.
Since this is an unsupported scenario, we have not investigated this in detail yet. Thanks for letting us know what you noted.

- Anu

Anutthara at 2007-9-9 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...
# 7

I am in the process of considering how it would be possible to use work items to track 'delivery' of a change to a system, from development, into testing, then staging and then live targets.

There is no 'requirement' to use multiple Team Projects to represent these delivery targets. The use of Team Projects has come about as a reflection of the branching model that I envisage.

I feel that Development will be task driven (i.e. work item), with the tasks originating from the need to develop code to implement a requirement, fix a bug, or implement changes. This process appears to fit in with the CMMI methodology.

Development work will take place on branches originating from a 'main' branch. Development when completed, will then 'deliver' an implemented requirement (i.e. Merge the correct changesets - I have a question about that - is there any tool or plugin that would allow the workitem itself to be merged, and pick up the chansets automatically?), back into the main branch.

Testing would then take place by selecting from the recently arrived requirements that need testing, from the main branch, into a testing branch.

The implemented requirement would then either pass or fail testing on the testing branch. Fail would see a bug generated (linked to the task that was originally raised to implement the requirement), a task to fix the bug and so more work on the development branch.

The same delivery of the implemented requirement would occur, from the 'main' branch' (following success in testing) into a staging branch and ultimatly into a live branch. Getting into live only if no bugs are foung in testing.

It seems that one of the keys to this process, is the linking of a single 'work item' (perhaps the parent requirement) to the various changesets resulting from the original work, and the subsequent merges into testing branches and live, in a way that would facilitate a top down (from the requirement) view of the progress of the analysis work, the development work, the builds, any bugs, delivery to testing, any bugs, and the re-works, staging and live.

At the moment, I see requirements, change request, and bugs as something central. Development or Support Team Projects would pick up work from a central pool, creating tasks inside their own specialised Team Project. So the requirements, change requests or bugs would be in a single central Governanace type of Team project, with implementation tasks created and assigned in the Development projects that would be linked back to the requirements.

Thanks for looking into our original build issue, we will arrange our process to avoid the checkin of code against the tasks (i.e. work items) of other Team Projects.

PeterHaynes at 2007-9-9 > top of Msdn Tech,Visual Studio Team System,Team Foundation Server - General...

Visual Studio Team System

Site Classified