If you've ever had to maintain a large, legacy .net app that has been around since 1.0 or even has some ASP 'classic' code in it, upgrading is a major nightmare. I know at least two shops right now 'stuck' on 2005 because various problems upgrading to 2008, let alone to 2012 or 2013 now. They are more likely to re-write the whole thing in Ruby at this point.

I'm actually running 2012 personally, not such a big deal on that front, my side projects tend to be pretty manageable and not hugely large or sophisticated.

But yeah, you have anything large and enterprise-y, the pain just amplifies each version you are behind.

To be honest I dragged a 1.5MLOC .Net 1.1 Web Forms and SQL 2000 application up to 4.0 and SQL 2008 R2 last year.

It wasn't that much of a problem. It took about 3 days and most of that was fixing deprecation warnings and porting the in house test framework to NUnit.

The real problem in the process was getting the build tooling and all the associated crap surrounding the solution up and running. This was also only because the muppets who wrote it originally put it together with sticky tape and string.

You can install several versions of Visual Studio side by side - keep an old version for maintaining legacy projects, use a new version for new projects.

Except you cannot have .NET 4.0 and 4.5 on the same machine, given the way 4.5 overwrites 4.0.

Version 4.5 was designed to be backward compatible to version 4.0 and is indeed an in-place update. Therefore after installing version 4.5 you will no longer have version 4.0 assemblies but you can still target version 4.0 using the backward compatible version 4.5 assemblies.

Nevertheless I have read some worries that some bug fixes (may) break backward compatibility and therefore projects targeting version 4.0 developed on machines with version 4.5 installed may behave differently when run on machines with only version 4.0 installed. If this is a real problem, that is if there are observable changes and therefore version 4.5 is not fully backward compatible to version 4.0, I can not tell.

UPDATE: There is a published list of breaking changes [1].

[1] http://msdn.microsoft.com/en-us/library/hh367887.aspx

Reality speaks otherwise,

http://www.west-wind.com/weblog/posts/2012/Mar/13/NET-45-is-...

http://stackoverflow.com/questions/11458159/how-to-keep-net-...

After reading through the two linked pages I can not see the relevance. The first article just discusses the in-place update but shows no (real) problems with that. The problem in the Stackoverflow question turns out to be caused by a bug in the OPs code and not by a breaking change between versions 4.0 and 4.5. Of interest may be the linked list of breaking changes [1] and given the size of the .NET framework it is a very short list.

[1] http://msdn.microsoft.com/en-us/library/hh367887.aspx

Note: The deleted comment was something like »This is not true«.

Even if there was only one issue, that is an issue to spend effort working around it if you're the poor soul that needs to do the fix for the product that broke.

I am still unable to see the problem. It's your decision if you switch to 4.5 or not. If you have projects targeting 4.0 and are unable to ensure that you code does not hit any of the documented breaking changes or if you are unwilling to take the risk of hitting unknown or undocumented compatibility problems, then don't switch to 4.5. Or take a hybrid solution - develop against 4.5 but test against 4.0.

We have deviated quite a bit from the original comment - you can install different Visual Studio (and .NET framework) versions side by side if you have to support legacy projects. There are some case where this will not work - obvious examples are .NET 1.0 not being supported since Vista, .NET 1.1 since Windows 8 - but there are still a lot of cases where this works just fine. If an side by side installation is not possible, you can still just setup up a second machine or a virtual machine for you legacy development needs. Not being able to upgrade Visual Studio because you have to support legacy projects is mostly a non-issue.

In our case teams that are supporting .NET 4.0 are not allowed to upgrade for .NET 4.5, precisely because of the .NET 4.5 bug fixes that lead to different behaviors between versions.