Tuesday, March 13, 2012

.Net 4.5 is what to .Net 4.0? [Replacement++] Or .Net 4.0 = .Net 4.5 but .Net 4.5 != .Net 4.0

Rick Strahl's Web Log - .NET 4.5 is an in-place replacement for .NET 4.0

"With the betas for .NET 4.5 and Visual Studio 11 and Windows 8 shipping many people will be installing .NET 4.5 and hacking away on it. There are a number of great enhancements that are fairly transparent, but it's important to understand what .NET 4.5 actually is in terms of the CLR running on your machine.

When .NET 4.5 is installed it effectively replaces .NET 4.0 on the machine. .NET 4.0 gets overwritten by a new version of .NET 4.5 which - according to Microsoft - is supposed to be 100% backwards compatible. While 100% backwards compatible sounds great, we all know that 100% is a hard number to hit, and even the aforementioned blog post at the Microsoft site acknowledges this. But there's so much more than backwards compatibility that makes this awkward at best and confusing at worst.

What does ‘Replacement’ mean?

When you install .NET 4.5 your .NET 4.0 assemblies in the \Windows\.NET Framework\V4.0.30319 are overwritten with a new set of assemblies. You end up with overwritten assemblies as well as a bunch of new ones (like the new System.Net.Http assemblies for example). The following screen shot demonstrates system.dll on my test machine (left) running .NET 4.5 on the right and my production laptop running stock .NET 4.0 (right):


Clearly they are different files with a difference in file sizes (interesting that the 4.5 version is actually smaller).

That’s not all. If you actually query the runtime version when .NET 4.5 is installed you still get:


There’s no real easy way to tell whether you are running on 4.0 or 4.5 – to the application they appear to be the same runtime version. And that is what Microsoft intends here. It’s intended as an in-place upgrade.



I'm of two minds on .Net 4.5. I kind of like that we're not back in the .Net 2.0/3.0/3.5 days. But I also don't dig the uncertainty I believe we're going to see... So if I understand the replacement idea, we can see support issue where someone has built a 4.5 dependent app (let's say using the new Yield in VB) but the user only has 4.0 and so they will break at runtime? If 4.0 is going away and will be replaced everywhere on every system with 4.5 via a mandatory Windows Update, then okay, I'm good. But that's not going to happen. So we're still in the .Net 2.0/3.0/3.5 kind of world, but one that's even more confusing?

I really like that 4.0 apps will "just run" on systems with 4.5.

I don't like that 4.5 apps will "mostly run" on systems with 4.0, until you run into a 4.5 feature at runtime.

I feel I've got to be missing something? Am I being stupid again and this really isn't the case? That at app start up we can know what version of .Net is installed and gracefully handle cases where our 4.5 app is on a 4.0 machine?

<snarkycomment>I'm sure we can build our Setup and Deployment packages to force .Net 4.5 as a dependency. Oh wait! There is no Setup and Deployment projects in VS11.. gee, I forgot. :| </snarkycomment>

I guess you could say that Microsoft (or the teams involved) are being agile and trying to constantly improve with each iteration, learning from the last...? (cough... so I hope at least... cough)


Related Past Post XRef:
Wish you had a cool and colorful poster with a snapshot of what's new in .Net 4.5?
"What's New in the .NET Framework 4.5 Developer Preview" (and Yield is coming to VB.Net!)

No comments: