Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Enterprise Developers Stuck on .NET 4.0

Enterprise Developers Stuck on .NET 4.0

Leia em Português

Whenever a new version of the CLR is released, such as .NET 2.0 and 4.0, developers are understandably reluctant to upgrade. CLR updates bring subtle changes to the runtime behavior that can break pre-existing code. Examples of this include the disastrous DateTime.Kind property or making uncaught exceptions on background threads terminate the process.

Conversely, library-only updates tended to be accepted with open arms. While many developers were not exactly rushing to adopt .NET 3.0 or 3.5, they didn’t fear it either. They just casually picked it up when they happened across something that they needed.

For .NET 4.5 we aren’t seeing the same kind attitude towards adoption. After an informal poll the overwhelming reason for staying on .NET 4.0 was Windows XP and Windows Server 2003. Though these decade old products are effectively at end-of-life, many companies are reluctant to leave them. Here are some of the quotes…

Pretty much all enterprise devs are stuck on 4.0 for a foreseeable future due to xp support.

We can't move to 4.5 due to needing to support XP for another few years due to clients not upgrading their out of date hardware. We still had users using NT a year into Vista being released.

GAH I'm stuck on 4.0 for Windows 2003 servers.

"Why spend money licensing on new OS when the old servers do what we need!" I'm told.

I do not agree with this assessment, but in small business, it's difficult to justify to the owner exactly what is wrong with .NET 4.0. There's nothing wrong with it. I don't think there's anything I can't do it it, unfortunately I'm stuck with doing things an older way.

One development team is working around this problem by removing the client OS from the picture.

We're addressing this by shifting more and more of the actual work to run on the server, leaving the client pretty thin with the eventual goal of eliminating a deployed client altogether in favor of running everything from the browser.

The other reason we’ve been hearing for staying on .NET 4.0 is the changes to Visual Studio interface. This next quote is not uncommon,

I'm stuck on .NET 4.0 due to 4.5 being tied to Visual Studio 2012. Me and my fellow developers really did not like VS 2012 interface. It looks like VS 2013 has improved though (not quite as flat and colorless as VS 2012), so perhaps we'll upgrade to that soon.

Rate this Article