Moving to .NET 3.0/3.5 – What to re-write and what to leave alone?

by Thomas | Feb 15, 2008 | Development

Reader Ravindranath posed several questions today in a comment, and I think that they deserve a post of their own.  Here they are again:

1. 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)?
2. When is it a MUST to re-architect and when is it optional?
3. 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)
• Robust IntelliSense for JavaScript
• 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:

1. 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.
2. 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.

Take Advantage of the ENTIRE Set of .NET Framework Class Libraries

by Thomas | Sep 20, 2007 | Development

Most developers tend to think in the context of the language they are currently writing.  If you’re writing C#, you are accustomed to having the core .NET Framework class library at your disposal.  If you’re writing VB.NET, you’re used to having many more classes above and beyond the core class library, and in J# (assuming anyone actually uses J#) you have yet another pool of classes to choose from.  This language-specific focus can lead to an unfortunate bit of tunnel vision.

To make a stunningly obvious point (once you think about it for a minute): your C# application is free to use any class available in the VB.NET or J# class libraries (or any others).  Your VB.NET application is free to use any class available in the J# class library, and so on.  Whatever language you are using, you can, and should, take advantage of all of the class libraries available to you!  Less work and less custom coding is always a great thing.

In the context of a C# application, this means adding a reference to Microsoft.VisualBasic.dll.  (What? Is he nuts?!?)  Sure, it might seem odd at first, but all high-level language code for .NET is reduced to one intermediate language in a managed code assembly — IL.  It makes no difference if it originated in COBOL.NET, C#, VB.NET, J#, etc., and there is absolutely nothing wrong with having “using Microsoft.VisualBasic” in your C# code.  The core .NET Framework already includes the extra VB class libraries, but to get the J# class libraries you need to have the J# Runtime installed.

There is a lot of great code just waiting to be used.  For example: need to work with ZIP files (unlike System.Compression)?  Check out the java.util.zip namespace in the J# runtime.  Yeah, that’s .NET managed code, despite the “java” in the namespace.  Remember that the J# runtime and J# itself was designed to be compatible with Java, so the runtime attempts to recreate as much of the (older) Java class libraries as possible.  Another example: the Microsoft.VisualBasic.Financial class.  How cool is this?  Asset depreciation calculation, present value of an annuity and more.  If you’re coding in C#, you may well have gone off and coded all of this yourself, or looked to open source for a solution — all while it was right under your nose.

I found an old article from MSDN magazine that demonstrates writing a ZIP utility in C# using the J# runtime, which is a great example for this topic.

Some of you will be saying “Duh!” by this time, but the reactions from years of saying this to developers has told me that it is not immediately obvious to everyone.  Hopefully this will save you some time!