Monthly Archives: June 2011

Migrating to TFS 2010 from TFS 2008

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

Workspaces Command

Advertisements

The Most Important Software Innovations

This article brings an interesting point to bear on the market of technology and software.

The Most Important Software Innovations

The author has omitted the changes in hardware and only included software advances. He explains his filtering of events well, so I won’t repeat it all. The thing I found most interesting was that the most profitable entites in the industry are almost non-existant in this list. The innovations came from people that at best got their name embedded in a type like George Boole (boolean).Microsoft is not mentioned, nor is DOS or Windows. DOS and Windows have historically benefitted from other’s innovation, and simply bought it or used it depending on what they could get away with. I guess in this case, the race is to the opportunist.

The money was made by those who leveraged existing ideas. The patents were usually filed by people other than the ones who actually came up with the idea, long after they were a fairly common thought by those in the industry.

I am not saying that it’s bad to leverage other’s ideas, it is how we make many things work. It was just a very educational read.