So hopefully you’ve already scanned through this other post where I cover the overall process I used for doing my updates. It also has some great tips and tricks for making the whole job easier using a few free tools, as well as a few links to helpful blogs and MSDN resources to save your sanity! So, that being said, here are some of the issues I encountered during my upgrade, and how I was able to work around or fix them. Again if you are using Hakan’s script and just running as-is, you might not see some of these errors. I just figure you learn more by screwing up, and I was working with some test projects and so had the luxury of being able to try out several different strategies without affecting anything critical, and so I did a lot of things by hand first.
First stumbling block I encountered during the upgrade was a weird issue with inconsistent “friendly names” for some of the fields. Essentially, I had some naming collisions when I tried to import some of the new artifacts like SharedStep.xml and TestCase.xml. You might at some point encounter an error message similar to “TF26177: The field XxxXxx cannot be renamed from ‘XxxXxx’ to ‘Xxx Xxx ’.” In other words, “Area ID” vs. “AreaID”, “Iteration ID” vs. “IterationID” and a few others.
The ones I was importing had field names that didn’t match EXACTLY. Now I started thinking, “But I am just re-uploading the work item type definitions that TFS was ALREADY using. They should be exactly the same right?”. I opened up the work item type definitions (thank you TFS Power Tools) and found that indeed, some of the field names did NOT match the ones on the server. You’ll note in the screen shot below that in just a handful of cases, a blank character was missing from the field name, so the import process sees this as a rename attempt. You are looking at a new Agile 5.0 Team Project work item definition on the right, and the standard Agile 5.0 Team Project work item definition used to create that new project on the left.
In essence, what I ended up having to do to rectify this was to go in and modify the work item template definitions for the appropriate work items to ensure that the field names being imported matched the field names on the server, before attempting to import them again. For me, it was an issue in both the ShareStep and TestCase work item type definitions, but certainly didn’t take long to fix. Once that was done, I had success!
UPDATE: Turns out some of the fields being used were of course already defined on the server from the previous implementation of TFS 2008, and when TFS 2010 was released a few of the names had been altered slightly. After struggling with this for an hour or two and somehow not running across the documentation stating that this was a known issue, I eventually figured out the fix on my own. Today, I was kindly pointed to a couple of places where this was documented, including a post by Gregg Borr that was pretty much written specifically to address this very situation ::facepalm::
Last thing we need to do is update the categories.xml. Silly me tried just importing the Categories.xml from the Agile 5.0 template which will of course NOT work because 4.2 requirements were named a bit differently than 5.0 ones. You’ll see something starting with “TF237059: The import of the category definition failed” because the new Categories.xml will refer to “User Story” and what you have is a “Quality of Service Requirement”. I opened up the XML provided with Hakan’s script because I was wanted to verify what was happening, and what I was doing wrong, and was not shocked to see that it was essentially updating the “Requirement Category” to support the new world order of work item types. RTFM Angela, RTFM. Here is what you will see in Hakan’s updated Categories.xml file:
So now my categories were imported correctly and I was feeling good but had to do some testing as I was SURE I would encounter some additional problems once I dug into Visual Studio and Microsoft Test Manager and started creating work item types in the new and improved Agile 5.0ish Team project. It was definitely a trip seeing the co-mingling of the 2 versions of the Agile template in the Team Explorer:
For the most part this all “just worked”. I created work item types, linked them together, created hierarchies, opened them in Project and Excel and made changes and published. Life was good. And then I tried to link a TestCase to a “requirement” in my new world. Wah, wah, wah, waaaaaaaah. Check out my third post for details on how I managed to fix this. Again, it could very well have been something I did wrong but it was a lesson learned…
Part 3 – Swapping in QoS Requirement for User Story