Moving to Visual Studio 2008 and Team Foundation Server 2008

Edit this page | 5 minute read

During the Christmas holiday, I started migrating my customer's development environment to the newest set of Microsoft development products. We already planned to do this a bit earlier, but since we had to wait for the first VS2008 CTP of the Patterns & Practices Web Service Software Factory : Modeling Edition, we simply couldn't. We are now two weeks further, so I decided to share some my experiences since then.



  • Well, I did not ran into any problems after the upgrade to .NET 3.5 while converting the existing Visual Studio 2005 solutions. I know about the advice to first upgrade the solutions, and then plan the introduction to .NET 3.5, but I couldn't resist.
  • If you choose to upgrade your solution to .NET 3.5 during the automatic conversion, it seems that only the web application projects (or web site projects) are modified to target .NET 3.5. I'm not entirely sure about this, but at least, that is what I've observed. Unfortunately, you have to go through each and every project one by one and change its framework version.
  • Beware that if you upgrade an existing ASP.NET 2.0 web site (or web application) to .NET 3.5, Visual Studio will automatically add an assembly redirect to your web.config that forwards any dependencies on the 1.0.61025.0 version of the System.Web.Extensions assembly to the corresponding .NET 3.5 assemblies. We did not notice any differences (yet), but if you do, you may need look in that area. All our existing control libraries (Obout, Telerik and the ASP.NET Ajax Control Toolkit) kept working without a glitch. There is a .NET 3.5-specific update of the AJAX Control Toolkit though.
  • You can't update existing WCF Service References (the .map files created from within VS2005) anymore. You need to re-add the reference from scratch. See this post for more information.
  • Although the installation of .NET 3.5 should not cause any troubles, we did not notice an anomaly after we installed Visual Studio 2008 next to Visual Studio 2005. The reason for this is that .NET 3.5 installer also installs two service packs on top of .NET 2.0 and 3.0. Apparently, we were using something that was wrong in the first place, but not detected by the compiler. Lucky, we invested heavily in unit tests and this one issue surfaced almost immediately.
  • The best thing you should do after upgrading to Visual Studio 2008 is read about LINQ. We are using Nhibernate in our data access layer and don't need LINQ-to-SQL, but still, LINQ is the best thing since Generics. Even if you don't like the query expression, simply include the System.Linq namespace and enjoy the power of the many extension methods it adds to your arrays, lists and other collection classes.

Add-ins & Tools

  • Beware that the Guidance Automation Extensions installer can only be installed once. You either have to choose to install it on Visual Studio 2005 or on Visual Studio 2008, but not both. Consider that if you're thinking about gradially migrating to 2008.
  • The Web Client Software Factory does not officially work with VS2008 yet, but it appeared that the hack suggested by this knowledge base article works quite well. A more official version is expected in February.
  • I discovered that the same trick also works for the Enterprise Library 3.1 installer. Obviously, EntLib is not compiled to .NET 3.5, but up to now, I did not find any issues related to that. Since the only changes with respect to EntLib is the service pack that the .NET Framework 3.5 installer applies to .NET Framework 2.0
  • The TFS Administration Tool is a beautiful little commodity that allows you to add or remove user accounts from TFS, WSS and SQL Reporting Services in a single click. Unfortunately, if you chose to upgrade Windows Sharepoint Services to 3.0 while upgrading from TFS 2005 to 2008, the tool does not work with WSS 3.0. For the time being, you have to fall back on the WSS Site Settings, but this will change soon.
  • After installing the Guidance Automation Extensions of May 2007 and the software factories, some of my colleagues using the Team Developer edition of Visual Studio 2008 ran into multiple occurrences of the "System.IO.FileLoadException: Could not load file or assembly 'Microsoft.VisualStudio.TemplateWizardInterface, Version=". As explained in this post, removing a single redirect from the devenv.exe.config solved the problem. It did not occur on a Team Suite install.
  • I personally believe that JetBrains' Resharper is the very best tool since Visual Studio. Version 3.1 does work with Visual Studio 2008, but its excellent code analysis features have some trouble with the new C# 3.0 keywords. Until the Early Access Program for Resharper 4.0 opens, I found an acceptable workaround that gives (most of) the best of both worlds.
    Simply disable Resharper's Code Analysis function and let it use Visual Studio's Intellisense . You may have to re-enable the IntelliSense settings under Tools->Options->Text Editor->C#->IntelliSense. Even though Visual Studio's IntelliSense cannot compete with Resharper's, assigning the Alt-Enter keyboard shortcut to View.ShowSmartTag gives you a bit of Resharper-style behavior.

Unit testing & Team Build

  • After upgrading, we noticed that while running unit tests, the Enterprise Library Logging Application Block could not find its enterpriselibrary.config (we moved the EntLib settings into a dedicated .config). At first, I thought it was a compatibility issue between .NET 3.5 and EntLib, but we also noticed that log4net was suffering from the same thing. After further investigation, I discovered that this is in fact a bug in Visual Studio 2008. As a workaround, we now have every test start with the following hack.
    AppDomain.CurrentDomain.SetData("APPBASE", Environment.CurrentDirectory);
  • Right after upgrading your test project, you may notice that the ExpectedException attribute does not seem to work anymore. This usually happens because your test project will still try to load version 8.x of the Microsoft.VisualStudio.QualityTools.UnitTestFramework assembly (which is part of Visual Studio 2005). Simply remove it and then reference the correct version 9.x of the assembly again. See also this post for more information.
  • If you have, like me, set-up your own workspaces from within your Team Build .proj file, you can now remove this stuff. The Build Definition dialog box allows configuring exactly which part of your source control tree should be included in the build.
  • In Visual Studio 2005, it was not possible to configure Team Build to run all the unit tests part of an assembly without falling back on a .vsdmi test file. However, Buck Hodges provided a nice replacement for MSBuild's TestToolsTask that did the job quite nice. Fortunately, Microsoft integrated this functionality into Team Foundation Server 2008 out of the box. Simply define an <ItemGroup> with a <TestCountainer> that includes a wildcard pattern for the assemblies that should be included. For instance:
    <TestContainer Include="$(OutDir)\%2a%2a\%2aTest.dll" />
  • Don't forget to go to Tools->Options->Test Tools->Test Execution and limit the number of Test Results during unit testing. Oh, and check out the new shortcut keys for starting/debugging the unit tests visible within the current context.

Obviously, this is not all. During the next weeks, I'll try to update this post with new experiences and solutions to common issues.


Leave a Comment