Recently, we upgraded our Team Foundation Server from 2008 to 2010 at work. Long overdue getting rid off some custom TFS Project templates, we were eager to use the new MSF for Agile 5.0 template. Now, we knew on beforehand that we couldn’t just upgrade existing team projects, so we had to come up with a migration plan.
First, we copied the Team Project Collection and “archived” a copy (NNN_Archive). Next, we created a dummy TFS Project with a Source Control root folder, and moved all the source code from all the existing projects into it. Next up, we created new team projects based on the aforementioned project template, and moved the source code back into the right folders in the VC tree.
Warning: We believed that doing it this way, we would preserve the VC history. Bummer! It did not! But since we had the archived TFS collection, we decided we didn’t want to revert to the backup, but just change to the other collection if we need to check the VC history in the future.
Next off, our architect and scrum masters wanted to migrate the work items from the archived collection to the new projects, so I had to brush off the dust of my TFS API skills and create a piece of throw-away code that would do the job.
Now, instead of just throwing away the code, I’m guessing that other people might need to do the same thing, so I’ve shared the source here.
You will have to tweak the source code to get it to work; the SOURCE_COLLECTION and TARGET_COLLECTION uri’s need to be set, as well as the TargetProjectName.
You will also have to tweak the WIQL query to return the work items you want to migrate – if you’re up for it, it shouldn’t be too hard to generalize the utility so that it would read the variables including the wiql from a configuration file.
Next up, you will have to adjust the MigrateWorkItem() method so that it copies the correct fields (optionally mapping to other field types in the new WI schema). The source code will copy attatchments – something that you also probably want to do. If you use the Links tab today, you will have to code up something that will lift over the links as well.
When you start the utility, you will be prompted with:
“Create [A]reas/Iterations or [M]igrate (Ctrl-C to quit)?:
The reason I did it this way, is that if you create the areas/iterations in the same pass as the work items, you will have to pause execution (Thread.Sleep) to ensure that the items has been commited to the TFS before the Work item is saved – IMO the two-pass strategy is cleaner.
Hope someone can reuse the code,
Build error: Value cannot be null. Parameter name: path1.
Now that’s a cryptic title, right?
First of all; a big thanks to Jason Barile/MSFT that set me in contact with Aaron Hallberg that in turned found a workaround for the bug I’m about to describe.
Second; The bug is fixed in MSFTs trunk version of TFS 2010, so you don’t need to run over to connect.microsoft.com to report it.
With the release of the Visual Studio 2010 and Team Foundation Server 2010, I thought it would be cool to check out the new TFS Basic mode running locally on one of my laptops.
I was amazed that the whole installation process took only about 20 minutes – something that is way better than the near-nightmare scenario of installing a full TFS 2005 or 2008 (I haven’t tried to setup a full scale TFS 2010 yet).
In addition to the TFS 2010 itself, I also installed the Team Build Controller and Team Build Agent locally on the same laptop (and of course Visual Studio 2010 Ultimate).
I imported a small pet project / demo I’m working on into the source control, and set up a build definition for it so that I could do continuous integration builds when checking in future changes.
Queue new build…
Bang. Build Error :-(
Now, I tried all sorts of things to try to figure out what caused the build failure, and I got some input from Jason Barile, that didn’t work out either (turned out that I’ve set the build server’s working directory to the same directory for it to drop the result to).
Luckily, I twittered my need for someone that could take a look at my problem, and that’s where Jason entered the scene; we did a SharedView session, and as I’ve already written, we didn’t get very far. But Jason works with a brilliant guy named Aaron, that was more than willing to take a look at the problem too.
We did a SharedView where we discussed what I’ve already tried, and tried to narrow down the possible things that could mess up my build. After checking up a bit internally, Aaron came back with a small piece of source code we checked out locally; a bit of code that tries to infer the location of MSBuild.
Well, it turned out that when it parsed a value from the registry (or something) it took my current regional settings into account, and here in Norway we use , (comma) as a decimal separator – something that is different from the US standard; . (period.
The fix for it was to hardcode the path to msbuild in the BuildTemplate.xaml file that is actually the workflow that is used by the build server. Aaron sent me a version that I plugged in – and bam! Green build!
Thanks again Jason & Aaron – I love the openness a great attitude of every MSFT employee I’ve met so far :-)
The modified .xaml file can be downloaded from here.