Category Archives: TFS
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:
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:
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:
I was facing yet another [ProjectName] “contains more than the allowed 259 characters. Type or select a shorter path.”
I have learned how to cloak these entries when they are not needed for the build I am doing, and we have also resorted to shortening the path names of some so that we can include them. But our base folders were pretty long so I decided to try and change them. I googled for the $(SourceDir) entry and found a couple of helpful articles:
From these I was able to change the entries in the config and Build Agent settings that would help me to shorten the path to something that would stop the madness of cloaking and avoid the above error (until we go above the limit again).
Here is what I did (this is all VS and TFS 2008):
I went to the Team Explorer in Visual Studio and right clicked on Builds and selected
I then inside the the manage selected my (only) build agent and got the window below:
Changing this from e:\teambuild\projects (which was a decent naming convention) to the shortened E:\Bld saved us 15 characters which solved a bunch of path length issues.
In addition, I changed the default “Sources” in the file
c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\tfsbuildservice.exe.config
from <add key=”SourcesSubdirectory” value=”Sources” />
to <add key=”SourcesSubdirectory” value=”Src” />
saving me an additional 4 characters for a full 19 characters of shortening.
This seems very silly in a world where we are trying to be more descriptive and I hope that MS will eventually let us do as we please with our file and folders, but it saved us some hassle and maybe it will save you some too.