Moving to .NET 3.0/3.5 – What to re-write and what to leave alone?
Reader Ravindranath posed several questions today in a comment, and I think that they deserve a post of their own. Here they are again:
- As a part of migrating from .Net 1.x to .Net 3.x, is it advisable to re-architect for the newer .Net 3.x features (WWF, WCF, WPF, etc)?
- When is it a MUST to re-architect and when is it optional?
- Are there any approach papers towards this?
There are two primary areas of benefit for those considering an upgrade from .NET 1.0/1.1 on Visual Studio 2002/2003 to .NET 2.0, 3.0 or 3.5: benefits resulting from IDE enhancements, and benefits resulting from .NET Framework enhancements.
First, let’s talk about IDE enhancements. Today, your IDE of choice should be Visual Studio 2008, whether you are using .NET 2.0, 3.0, 3.5 or are considering an upgrade from .NET 1.0/1.1. VS2008 is the first Visual Studio IDE for .NET that can target multiple versions of the .NET Framework, so if you are using .NET 2.0 today, you have nothing to lose and everything to gain by moving from VS2005 to VS2008.
Just a few of the benefits of Visual Studio 2008 include:
- Completely new CSS-oriented ASP.NET designer, shared with Expression Web (formerly FrontPage)
- Improved code analysis (FxCop) tools
- Improved performance analysis tools
- Team Explorer 2008 client for Team Foundation Server 2005/2008, with an improved Source Control Explorer
Since Visual Studio 2008 is still a new release, there are some Visual Studio IDE extensions that haven’t been upgraded yet. Depending on how important those are to you, it’s possible that you could be forced to wait for updates. Two notable examples are BizTalk Server 2006 R2, which requires VS2005 and has no announced timetable for a VS2008 update, and Microsoft’s Enterprise Library, which includes a configuration editor plug-in that is not VS2008-ready. Enterprise Library has an easy workaround since you can either use the standalone editor or hop over to VS2005 for configuration tweaks, but BizTalk’ers are out of luck.
Now to move on to the main focus of Ravindranath’s questions: upgrade benefits resulting from .NET Framework enhancements.
The .NET Frameworks 1.0, 1.1 and 2.0 were completely isolated from each other, but that changed with .NET 3.0 and 3.5. The .NET 3.0 and 3.5 Frameworks can be thought of as layers on top of each other. In fact, as I’ve written about previously, .NET Framework 3.5 requires both .NET 2.0 SP1 and .NET 3.0 SP1. ASP.NET has, in fact, remained at version 2.0.
Projects upgrading from .NET 1.0/1.1 to 2.0/3.0/3.5 will gain their major benefits not from features in 3.0 or 3.5, but from the CLR enhancements introduced back in Framework 2.0. In most cases you will find immediate performance and memory usage benefits with a straight conversion to 2.0, making no code changes except in the rare cases where you might have used a method or class that had a breaking change in 2.0.
My answer to question #1 is generally No, and my answer to question #2 is that redesign is never required. Now, of course, I have to qualify that with a couple of caveats, and put some logic behind my answers.
First, it really depends what kind of application is involved and what is important to the business behind it. My primary example here is Windows Presentation Foundation (WPF). If your application is a consumer-focused application where graphics and fancy look-and-feel are very important, then yes, it makes sense to take a very hard look at moving to WPF. You will never reproduce what WPF can do in Windows Forms — although even that requires the caveat that WPF controls can be hosted inside a Windows Forms application!
If you really need the full power of WPF and your app is currently Windows Forms-based, you’re really looking at a rewrite, not an upgrade. WPF carries with it a significant learning curve, immature tools and third-party libraries and a major time investment. I do not discourage its use, but you do need to have good reasons and a real need for it, and know what you are getting into. In another year or two, there will be no reason not to build all smart client apps with WPF, but we’re not there yet.
Second, there is often no good reason to rewrite your ASMX-based Web services with Windows Communication Foundation (WCF). ASMX is still supported, and it will remain in the Framework into the future.
There are two main reasons to rewrite existing ASMX services with WCF:
- You have an explicit need for the WS-* features introduced in WCF and cannot get by with the WS-* subset in the Web Services Enhancements add-ons.
- You need the ultimate in performance from your service.
I recommend without qualification that all NEW services (which can be anything from an MSMQ listener to a web service to a self-hosted TCP endpoint) and service clients be written with WCF. Once again, you will experience a fairly significant learning curve, but WCF is the communication framework of the future, so you’ll have to learn it eventually. Of the major new subsystems in .NET 3.0/3.5, WCF is the one that most developers will use most often, and it is the first one to learn.
That leaves Windows Workflow Foundation (WF) and CardSpace, and these are the least common. As with most security-related programming tools, CardSpace will never excite much developer interest. I think it will remain a niche tool. On the other hand, WF has a lot of potential, but it also takes the most time for developers and architects alike to fully comprehend how to put it to use. One sample that is out demonstrates the automation of a Windows Forms form using nothing but the WF rules engine to drive validation and enabling/disabling controls as values and control focus changes. Normally this would involve dozens of event handlers and many lines of code in even a relatively simple form, but this sample has almost no code behind the form. That’s a pretty slick example of just the WF rules engine, which doesn’t even address the actual workflow engine.
So, to recap, in most upgrade scenarios from 1.1 to 3.0/3.5, I think you will be best served by a direct upgrade, not a rewrite. Then evaluate, in order, where you might be able to put to use WCF, WF, WPF and CardSpace, but don’t rush to use any of them just because they’re there! You will gain huge benefits just from the improvements in the 2.0 CLR and Framework and in the newer Visual Studio IDEs, so enjoy those improvements without too much worry about the 3.0 alphabet soup. You’ll find a use for them when the time is right.
Finally, I am not aware of any specific papers including guidelines for when to re-design or not in these areas. Generally, I would look to MSDN and primarily the patterns & practices team for this type of analysis, but I haven’t seen anything yet. If any readers know of related papers, please feel free to post links in the comments.