Status :

Description

Our 2008 builds are failing after installing Visual Studio 2010. First DeleteWorkspaceTask is not able to delete existing workspaces. Then after manually deleting and re-running, we ran into some other pre-reported issues, e.g. GenCheckinNotesUpdateWorkItems fails because AssociatedChangesets parameter is not supported. Why would a 2010 studio (not even build) install step on the 2008 build mechanism? Our work-around right now is to install 2010 build items on a box that doesn't have 2008 team build.

Assign To

Thanks for reporting this issue. The problem is that in 2008 the workspace name needed to be unique to the machine and the build definition, while in 2010 it needs to be unique to the machine and the build definition *and* the build agent (since there can be more than one agent per build machine in 2010). As such, the name of the workspace created by the 2010 targets file is slightly different from the one that was created by the 2008 targets file, leading to the issue you have seen.

You can work around this issue by either (a) deleting the existing workspace - thereafter the workspace used for the build will have the new name, or (b) manually set the WorkspaceName property back to its old value in your TfsBuild.proj file. Something like:

Note that this issue only occurs on build machines which are upgraded from 2008 to 2010 when they run builds for build definitions they had already run builds for. That is, it will not occur on new 2010 build machines, and it will not occur for new build definitions even on upgraded machines.

Posted by Microsoft on 3/4/2010 at 7:03 PM

Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)

Our work-around right now is to install 2010 build items on a box that doesn't have 2008 team build. The known workarounds to get 2008 working again are not acceptable for production.

Posted by dzimmy on 3/4/2010 at 6:24 AM

Correction: The build breaks in other places as well after manually deleting workspace. (But see that issue is known: https://connect.microsoft.com/VisualStudio/feedback/details/532682/error-msb4131-the-associatedchangesets-parameter-is-not-supported-by-the-gencheckinnotesupdateworkitems-task-verify-the-parameter-exists-on-the-task-and-it-is-a-gettable-public-instance-propert?wa=wsignin1.0)

Posted by dzimmy on 3/4/2010 at 6:06 AM

Manually deleting workspace allowed build to go through. (We will see if the subsequent build which uses the same workspace fails.)