This is a quick summary of our experiences moving from TFS 2008 to TFS 2010.
If you are like us (and many others) out there, you are building an msi to deploy your projects and you are using TFS to do it. We had to run DevEnv in our build script to accomplish this because MSBuild does not support the web deployment project and will give you a warning that it is skipped if you have it included in a solution that is sent to build.
In VS 2008, you can accomplish this in your build script, and it is a bit messy, but works (it also builds the entire solution twice, ugh!). I am not going to go into those details, but you can find more here and here.
So we created a new branch in TFS 2010 and brought over the code we are migrating and first I ran the build using the same TFS 2005 script that we have been using (in 2005 and 2008). This was a tfsbuild.proj file. To do this I used the 2010 build xaml file that reads in this tfsbuild.proj script called upgradetemplate.xaml.
This worked after a few config changes (we had shortened the names of some of the default configuration values in the build config because of the visual studio – MSBuild directory structure limit workarounds.
The build worked and then we migrated the solution to VS 2010.
This worked with only a few quirks where VS 2010 forced some projects to be upgraded and would not load them otherwise because of version mismatches. We also found out Test Projects in Visual Studio 2010 Must Target .NET Framework 4.
So I got the .Net framework versions all happy with one another and then the project built locally on my dev box.
We started out assuming that we could not use Web Deployment projects in VS 2010, and started looking at alternatives. There are mixed messages out there. But a coworker found this:
Download details: Visual Studio® 2010 Web Deployment Projects – RTW
This is a fix that adds the Web Deployment Project back into VS 2010 allowing us to still build our msi file from DevEnv. This allowed us to use the script that calls DevEnv pointing to the VS 2010 installation on the build server.
So I sent it off to the build server. Success! That wasn’t so bad… Now for conversion to the defaultTemplate.xaml that would allow us to use the nifty build workflow UI.
I followed the instructions for Building Visual Studio Setup Projects with TFS 2010 Team Build. This was very helpful in putting this together initially and I had a hard time finding it, so here is one more reference for you all.
When I started the build, it came back almost immediately with: The path … is already mapped in workspace VMLSBUILD_6_1.
This was an interesting one. It turns out that there are caches of the workspaces and while TFSBuild 2008 didn’t seem to mind, TFS2010 did. When I ran Team Foundation Sidekicks to see what the issue was, I found a lot of residual workspaces – some years old – that were just hanging out there. For some it is not as simple as my fix, but all I had to do was delete the workspaces and I was back in business.
You can also view your workspaces by running this from the Visual Studio Command Line on the box that contains the build workspaces:
tf workspaces /owner:* /computer:”BUILDCOMPUTERNAME” /s:”http://yourTFSServerURL”
OK, kicked the build off again…
Then I ran into the error: “Package ‘Microsoft.VisualStudio.TestTools.TestCaseManagement.QualityToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ failed to load.” This is a pain, but the workaround is not so bad:
Package Microsoft.VisualStudio.QualityTools.TestCaseManagement failed to load in Team Build 2010. | // TODO: name this blog
Thanks to Scott for that – it was a simple solution once you saw it, but I hadn’t thought of it.
One more time to the build, and we were successful.
Edit / Note: The above fix does not guarantee that this issue doesn’t come up, but instead is a symptom of other build issues in DevEnv.com. If this error is encountered, as the blog states, you have to dig into the log and see what the true issue is. I have not found a good way to reflect the true error out to the build, but at least you have a way to get to it.
Hopefully this helps out someone who is doing the same as we are. Peace…
A few more links:
TFPT Error: Unable to determine the workspace – Ozzie Rules Blogging – Site Home – MSDN Blogs