Visual Studio 2005 or 2008? What's more risk?

Should I stay or should I go … with Visual Studio 2005 or 2008 is the question in this particular case. One of my customers is still on Visual Studio 2003 and they are wondering whether to upgrade to VS 2005 or to VS 2008.

Are there reasons for moving to VS 2005 instead of 2008 even though 2008 is so close to release? Minimizing risk is probably the major driver for deciding on VS 2005. After all, it’s been out in the market for almost two years and it’s stable and mature. There’s also the common wisdom that you shouldn’t deploy a Microsoft product that doesn’t have at least one service pack. Mind you that SP1 for Visual Studio didn’t come out until 12 months after the release of the product. Microsoft is no longer in the mode where the Service Pack has to hit 6 months after release because there were quality issues that needed to be fixed.

When it comes to determining to move to the newer Visual Studio 2008 and the .NET Framework 3.5 there are more points to consider:

1) Stability and maturity of the underlying framework and consequently the applications you’re building on top of the framework.

2) Stability and maturity of new features added with VS 2008

3) Product Support differences.

4) Productivity benefits of VS 2008 compared to VS 2005.

Let’s dive a little deeper and examine each of these points:

1) Enhancements to the .NET Framework are built around the stable core of Version 2.0 that ship with Visual Studio 2005, when additions like generics and partial classes required modifying the CLR.

Version 3.0 added to the core set of .NET 2.0, but does not change the core CLR. New functionality is packed in new assemblies, e.g. System.ServiceModel. There were some minor changes to some of the library assemblies, e.g. System.Runtime.Serialization to accommodate new WCF functionality, but by all and large 3.0 is built around the solid core of the CLR and the BCL of 2.0.

Version 3.5 follows the same approach. The 2.0 CLR/BCL core remains largely untouched. New features are either implemented at the compiler level or in the System. Core assembly. Scott Hanselman (who’s finally joined Microsoft) confirmed this claim by doing some deeper research recently. He compared the core libraries that shipped with VS 2005 and the Beta 2 release of .NET 3.5 and found that the percentage of churn was in the single digits.

Since the .NET Runtime and the core libraries are pretty much the same between VS 2005 and VS 2008, there’s no increased risk for applications that leverage core .NET functionality only.

2) Now that we realized that .NET is very stable at its core, let’s look at the additional functionality that’s new with .NET 3.5. There are quite a number of new features (WCF, WPF, Visual Studio, Linq, too many others), but this particular customer is very interested in the new AJAX features. Again, the core framework code at the ASP.NET Ajax framework level has been in the public as a CTP since 2006 and has been RTM since early 2007. The Visual Studio 2008 release is adding more server side control features (for example control extenders), but the core has been publicly available as a preview release for more than 18 months. Another customer I work with is running one of the world’s largest eCommerce sites on top of AJAX some of these CTP bits without impact to their business.

Visual Studio 2008 adds design time tools and more server controls for richer UIs and better communication between the client-side code and the server. Those features are very helpful and the runtime features have been available in CTPs for a while.
Finally, one more risk mitigation factor to consider is recent announcement that source code (with comments) and debugging symbols are going to be available with Visual Studio 2008 and .NET Framework 3.5. If you’re running into issues, you have the unprecedented ability to trouble shoot and diagnose problems.

With all that, my take would be (if I was an architect that didn’t work for Microsoft) that risk from new framework libraries around ASP.NET AJAX is manageable. In other areas, you get all the fixes for .NET 3.0 SP1, which means there’s actually a benefit of fewer pieces to install. The remaining risk is the new code in System.Core and in some other places. Still, I’d feel good about moving to 2008.

3) Now, you may argue that the tools are still new, and there’s some truth in that. Even though the quality of Visual Studio has been pretty good, much better than in the 90s when I first looked at Microsoft tools, but new code is always new risk. One could argue that VS 2005 + VS 2005 SP1 + .NET 3.0 + .NET 3.0 SP1 + ASP.NET AJAX RTM + AJAX Control Toolkit + ASP.NET AJAX Futures CTP gives me the same capabilities as VS 2008 with more stable, proven code. But consider this: The AJAX Control Toolkit is released under a community license, which means there’s not official product support through the Premier Support channels. The ASP.NET AJAX Futures CTP delivers some of the cool improvements over RTM, but the CTP is an unsupported product. The new controls that ship with VS 2008 are fully supported.

You’re actually increasing risk a little bit by staying with Visual Studio 2005 because of a few unsupported bits and you’re greatly increasing complexity of your install process. With VS 2008 you get the stable service pack code for Visual Studio and .NET 2.0 and 3.0 and you get all that in a single install and you get all that in a single install which reduces complexity and consequently risk and cost of deployment. I give that one to Visual Studio 2008.

4) Yes, there is new code in Visual Studio 2008 and there better be ;). VS 2005 has been lacking the tool support to take full advantage of the .NET 3.0 platform. VS 2005 shipped with .NET 2.0, remember? The .NET 3.0 release was only a framework release. The tool support for WPF, WCF and ASP.NET AJAX is finally shipping with VS 2008.

The improved Javascript IntelliSense support alone is a great enhancement for somebody like me that delegates mundane tasks like remembering method overloads and signatures to IntelliSense. AJAX was painful because IntelliSense in the code editor was rather limited.

Then there’s the client-side JavaScript debugging Scott Guthrie was talking about. You now can set breakpoints from the start, debug and inspect javascript variables with property grids, visualizers and an immediate window just like you can in with managed code on the server.

Then there are other very helpful new features, like the ability call WCF JSON services, the Web Designer with rich CSS Support or the built-in support to make the back button AJAX aware with the history control and, of course , Linq. There are many other exciting new features, too many others to list here, but the bottom line is, there are numerous reasons why VS 2008 is the better choice for developing AJAX enabled sites.

Finally, you could argue that VS 2008 actually gives you the best of both worlds because VS 2008 lets you target different versions of the .NET Runtime. If you’re feeling very strongly about shipping applications on the 2.0 bits or the 3.0 bits, you can still take advantage of the new productivity enhancements in the IDE but build against the framework version of your choice.That's a great combination or productivity and stable code to optimize for low risk.