Why do projects opt to stay on an older framework version of the .NET Framework?

For example, staying on .NET Framework version 3.5 which was released in 2007 instead of upgrading to the latest 4.5.1 version?

Jon Skeet's Noda Time also targets .NET 3.5. Why?

  • Why migrate if the code is stable. I only consider migrating when the version is no longer supported (I.e 1.0, ect ) – Ramhound Apr 6 '14 at 21:49

For .NET it may depend on the deployment target. .NET 3.5 is supported in even early editions of Windows XP, whereas 4.5 is only supported on Vista and above.

At my workplace we opted to stay on 4.0 because we still have workstations running on Windows XP Pro SP3 (which 4.0 supports). We cannot consider migrating until next year or so just because of that.

Another reason may be a dependency on external code libraries that have been compiled using an older version of the framework and for which no recent version exists.

| improve this answer | |
  • and sometimes you can't upgrade. My MMC snapin (on windows 7) only works with .NET 3.0, and some places don't want to ship the framework - so they go with what came with the OS, in Windows 7's case that's .NET 3.5 – gbjbaanb Apr 6 '14 at 21:55
  • 1
    I saw .NET 2.0 targeted by products I worked on for many years for this exact reason. This sort of thing is what separates professional and hobbyist developers - it may have nothing to do with skill level. The professional often has an existing market/install base to think about. When I go home from work it can be refreshing not simply because I can code what I like but also I can be free of some of these burdens. – J Trana Apr 7 '14 at 4:03

"Good enough is the enemy of better." -- Jerry Pournelle

Seriously, there has to be a reason for an upgrade besides just "ooh, shiny!". Among other issues, any time you switch versions of a package your code depends on, you switch out one set of bugs that you're adapted for to another set that you may not be. In the process of switching, you frequently have to make code changes because of API differences or undocumented changes in behavior. And the list goes on.

There's another question to be asked: "Why do projects opt to upgrade to a newer framework version?" Ideally, the answers will say something about the value to the project or its constituency of the upgrade. For example, with a commercial framework, the inability to get professional support for the older version. More often than not, the answer is "To take advantage of a capability not present in the older version.".

| improve this answer | |
  • 2
    I've never heard this quote from Pournelle. Are you sure you're not referring to "perfect is the enemy of good"? – Aaronaught Apr 6 '14 at 14:29
  • 2
    @Aaronaught That's Voltaire, quoting someone else he never identified. Pournelle wrote a column for about 20 years in Byte Magazine, and this line was a frequent refrain explaining why he continued to use something that was "good enough". Pournelle being whom he is, I've always assumed he was riffing on Voltaire. – Ross Patterson Apr 6 '14 at 18:15

Recommend an upgrade to a million dollar software project from v3.5 to v4.0 (Not always the same as going from .50 to 1.0), you better have a very good reason. Sorry, but just stating it's 5-10 years old isn't good enough IMHO.

Be prepared to identity the new features and how they will benefit this project. You could argue that if you don't, making an even bigger jump of 3.5 -> 6.0 will be exponentially more expensive because the creator of your programming code won't provide any sort of automated way of doing it as an example.

When you're paying the bills, it's easier to take comfort in "If it isn't broke, don't fix it."

| improve this answer | |
  • 2
    Being 5-10 years old usually is a pretty good reason. If it were a car, it would be out of warranty. It's a similar situation with software; unless releases are very slow/infrequent, it's probably no longer supported or only minimally supported as a legacy product. If there's any notion of plugins or integration, most of it probably won't work on the old version. And lack of updates means that potentially serious security flaws or other show-stopping bugs haven't been fixed and might never be. And of course, as you mention, going up 1 version now is far less expensive than 3 versions later. – Aaronaught Apr 6 '14 at 19:30
  • 5
    Poor analogy. A 10-year old car has 10 years of wear and tear on it. Software is just as good (or bad) as it was on day 1. It won't fall apart halfway just because it's old. – scrwtp Apr 6 '14 at 20:09
  • My car's 8 years old now, and it still works fine. 'course I bought an expensive, well built car rather than some cheap n cheerful runabout. My parent's house is roughly 40 years old, and still standing. And I used to drive across a bridge that was built several hundred years ago. Maybe these analogies holds up better than simply looking at age as a simplistic number - quality matters far more. – gbjbaanb Apr 6 '14 at 21:59

Providing support for an older OS is one reason (see Crono's answer). The other reason is to "save money". Quoted because it only saves money on the short run.

It depends on the type of project of course, but for business applications, which usually survive a significant number of years, there's a good chance an upgrade will be required at some point, for whatever reason: support for newer platforms, new features, better performance...So either you postpone the upgrade until you have no other choice, or you continually upgrade as part of the normal development routine.

Small, quick, cheap steps, or big, slow, expensive steps. It's exactly the same problem as with refactoring. Actually I guess you could even say a framework/library upgrade is a kind of refactoring.

Side note: There's a discussion in the comments of JeffO's answer about the car analogy. Since my rep is too low to comment, I'm leaving this note here. Software does not get old as a car does if it's left untouched, yes, but it does get old if it's worked on. Code is added. It gets bloated. Just as a car, if you don't continually replace parts of it, something breaks. In the case of a car, you can still replace the part that's broken, if it's available. With old software, finding and fixing the issue gets so expensive with time you eventually have to give up.

| improve this answer | |
  • Depends on the type of bug. If there is a dependency that is causing a bug, updating that dependency may fix it. But if there is an internal bug in a closed-source library, you are out of luck. – user22815 Apr 7 '14 at 17:14

Targeting a newer version of .NET when your application doesn't rely on anything from the latest version of .NET is unnecessary, unless the target framework itself is reaching end of life. You're introducing additional work to upgrade and test your application with no real benefit.

With that being said, we've had some software in our group that we've upgraded in the past from .NET 2.0 or .NET 3.5 to .NET 4.0. In most cases it was because we wanted to take advantage of the Task Parallel Library to improve performance.

We can't upgrade anything to .NET 4.5 yet in our organization because it hasn't been rolled out to any of our environments

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.