Late last year (late November 2007 to be exact) Microsoft released Visual Studio 2008 with .NET 3.5 to production. This has generated a lot of buzz around the new features, what’s hot, what you should be looking into, and so on. The beta cycle for VS 2008 was long and very public. There has been a lot of articles and access to the new features for a while but now it’s here, now it’s real. People can go and buy VS 2008 today or download it from MSDN. Teams that have been just wondering how to go about the upgrade now need to answer the question: how do we upgrade?
Most software developers are technology driven so we love new tools and technologies. This seems to be a personality trait regardless of the technology that we chose. The desire to move to the latest and greatest version seems to be as strong in .NET developers today as it was for FoxPro and VB 6 developers in the late nineties. We crave the day when we can use new tools. Yet, we have a responsibility to our users in doing this responsibly. Upgrades can be hard to perform on medium to large systems that have large number of users in production. Like most things on these kinds of systems upgrades need to be planned in order to give the most to the customers.
Although the decision to upgrade or not to upgrade to a new version of development tools is very specific to every project, I usually tend to recommend upgrading on-going projects (with new features actively being developed) and thinking twice before upgrading projects that have been switched to maintenance mode (no new features are being developed.)
If updating a project to use the latest technology options for you environment takes time and money, why would you even consider want to upgrade? The fact that a new version of your development tools is available is hardly enough reason for a team to stop developing new features, spend days/weeks performing the upgrade, retest the system, and then continue with new development. There has to be some benefit for the customer for an upgrade to make sense.
New tools do come with benefits, but you need to be realistic about what will your project benefit from in the short and long term when upgrading to a new version. I tend to be wary of short term “magic” benefits that come with new development tools. One of the most common mistakes that teams do is promise (to themselves or to others) that productivity will increase incredibly with new version of the tool. Thinking that your application magically will be developed in half the time and will look much better than before just because you switched to VS 2008 and WPF is foolish. Assuming that the Windows Workflow engine in .NET 3.0 will solve all your workflow issues when you have never used a workflow engine before would also be a poor assumption. It takes time to get used to new tools and to learn what really works for your project and what does not.
In the case of Visual Studio 2008 there are a ton of benefits that apply to a wide variety of projects. A lot of the tools that Microsoft made available more than a year ago when it released .NET 3.0 are now finally easy to use for most of us. VS 2008 provides the (long awaited) designers to make the most of WPF, AJAX, WCF, and LINQ to name a few. These new technologies can indeed help your application look better, be more responsive to users, provide better communication with other applications, and such.
Although the process to upgrade a project to use a new tool varies from project to project there are two main guidelines that I’ve found useful. One is to try the upgrade first in a test environment and with ample time (i.e. don’t try it the week before going to production.) The second is that you need to consider the entire project, not only the source code (How will the deployment be affected with the new tool? Will the users be affected? Will third party tools need to be upgraded as well?)
In my experience tests in the testing environment with the new version of the tool always work out and come out with glaring reviews. The issues with the new version of your tool usually show up once you’ve upgraded the entire system. The testing environment, although necessary, usually only covers a small portion of the system (e.g. the code but not the deployment) and some of the pitfalls might be in those other areas that will be upgraded later. This can be sort of a catch-22, you need to test the upgrade first to get an initial idea but you won’t get a good idea until you’ve upgraded the entire system. You can try to evaluate a wide range of areas of your system (code, deployment, third party tools, et cetera) but don’t hold your breath -- you might still run into issues once the entire app is upgraded. C’est la vie.
In the case of Visual Studio 2008 Microsoft did a tremendous benefit to the .NET developers by allowing projects to be upgraded to use VS 2008 and still target the .NET 2.0 runtime. This is a huge advantage for teams that need to take more time to upgrade since it allows them to upgrade the IDE but keep the runtimes and code the same. To make things even better once you've switched your project to use the .NET 3.5 runtime you can incorporate .NET 3.0 features little by little. For example, it is possible to have Windows Forms and WPF forms on the same application, which means that you don’t need to rewrite your entire user interface on day one. You can keep your existing Windows Forms and only upgrade to WPF one of two forms at a time, become comfortable with the new technology and plan how to (or if you want to) migrate the rest of the application to use WPF.