Monthly Archives: September 2014

To upgrade or not from .NET 3.5 SP1 to 4.0?

You have 1.5 months of development for the new release. Yet you flagship, baby, piece of art, or whatever you refer to this master piece of software you have put together is running on .NET 3.5 SP1.

Your third party vendors are already at .NET 4.5. In fact, you cannot get third party support for .NET 3.5. It also just pains you to see that your software is running version 11.2, for example, of your third party vendor product, while they are currently at version 14.1. You cringe at the effort it would take to get this source code up to date.

Another thing that complicates matters is that you already started porting your code to .NET 4.0. Not 4.5, but 4.0. But then things happened. Some new process was introduced which sucked away a solid 3 months of development time leaving you 1.5 months to scramble stuff together. You had already fixed some bugs in this partial .NET 4.0 upgrade and while doing this identified some issues that arose from the upgrade.

In this case, what would you do? Stick to .NET 3.5 or move on to .NET 4.0?

I am a tools guy. I like working with the latest tools and frameworks to take advantage of all the good work the folks at Microsoft are doing. But this is the classic case, and cause of pain, when you have to put aside your love affair with shiny new stuff coming out of Redmond and do some business risk analysis.

Some questions to help with the decision are:

1. Is an upgrade to .NET 4.0 entirely necessary now? Did Microsoft address some critical security threats as part of the framework upgrade?
2. Can the issues identified in .NET 4.0 be fixed in a couple of days?

If the answer to 1 and 2 are no, stick to .NET 3.5 SP1 and schedule an upgrade for .NET 4.0, in this case, in your next release. Well, if you have no such constraints, just do it.

Maybe you can find solace in the fact that there are still some shops shipping out software running on .NET 2.0