.NET 4.5 Compatibility And Multi-Targeting

by Roopesh Shenoy on Apr 06, 2012 |

The upcoming .NET Framework 4.5 being an in-place upgrade to .NET 4.0 has given rise to concerns on how this can introduce breaking changes as well as make multi-targeting difficult. In his article “.NET Versioning and Multi-Targeting..” Scott Hanselman addresses these concerns.

First of all, what is the difference between an in-place upgrade and a side-by-side install?

Side-by-side means that different versions of .NET can live together on the same machine.

In-place upgrade means that the CLR is the same but new libraries are added as well as bug fixes and performance improvements

.NET Framework 4.5 is an in-place upgrade and it also updates the assemblies carried from .NET 4.0 – this has been cause of much worry, especially expressed by Rick Strahl in his article .NET 4.5 is an in-place replacement for .NET 4.0.

Scott clarifies -

.NET 4.5 is not a radically different side-by-side CLR. A new CLR would be a theoretical .NET 5 In my opinion.

It's possible something could break but unlikely according the .NET Blog. Here are the known .NET 4.5 breaking changes - most are pretty obscure. The kinds of breaking changes I've seen myself in the wild have been primarily when folks are relying on reflection or internal data structures. These internals aren't public contracts so they may have changed.

Another cause of concern is multi-targeting - if .NET Framework 4.5 upgrades the .NET 4.0 assemblies as-well, how will you use a development machine with .NET 4.5 installed to target .NET 4.0? Scott demystifies this - the old .NET 4.0 assemblies are in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0 folder.

.NET Framework 4.5 is currently in public beta and will be released alongside Windows 8 and Visual Studio 11. There are several new features and we have explored quite a bit of these earlier on InfoQ. You can also refer to MSDN for more details

Related Editorial

APM Survival Guide from a Veteran Performance Geek

Cloud Computing Demands Enterprise-Class Password Management and Security

Continuous Delivery: A Maturity Assessment Model

Betfair Chooses not to Gamble with Database Performance: An AppDyanmics Case Study

Cloud Identity Buyer’s Guide: Managing Identity in the Cloud

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

How does using a 4.5 machine for 4 development actually work for the dev. by Mike Gale Posted

Re: How does using a 4.5 machine for 4 development actually work for the de by Roopesh Shenoy Posted

Re: How does using a 4.5 machine for 4 development actually work for the de by Mike Gale Posted

How does using a 4.5 machine for 4 development actually work for the dev. by Mike Gale

There's a comment in the article about using a 4.5 machine to make 4 code.

The text isn't entirely clear to me.

Scott demystifies this - the old .NET 4.0 assemblies are in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0 folder.

If I'm using Visual Studio, will there be a option for the framework version say ".NET 4.0 original" versus ".NET 4.5" (also Client profile)? If not how will the developer actually do this?

Re: How does using a 4.5 machine for 4 development actually work for the de by Roopesh Shenoy

Yes, that's what this means - targeting 4.0 will target the 'original .NET 4.0' and not the dlls that are updated with .NET 4.5.

The question was where will VS get the original 4.0 dlls when they have been overridden by 4.5 - the answer is that the original bits are still saved in the above folder and this is what is used to target 4.0.

Re: How does using a 4.5 machine for 4 development actually work for the de by Mike Gale

Thanks Roopesh. The picture I now have is a dev environment that gives a choice of .NET 4 and 4.5. That answer's Rick's point. I guess there's a detailed article in the works, somewhere, about this. (This has caused some deep seated unease, not always expressed, among developers. I'm personally looking forward to 4.5, having been nuked by a fault in 4 that actually prevented normal debugging of a web service. It's not going to be patched! MS found a work around for me. My personal testing, on a real application, of 4.5 revealed no issues.)