If you’ve looked at .NET 4.0 at all then I’m sure you’ll be aware that .NET 4.0 bears a similar relationship to .NET 3.5 Sp1 that .NET 2.0 did to .NET 1.1 in that the underlying Common Language Runtime has changed.
This hasn’t happened for quite a while.
The CLR has remained at “version 2.0” since .NET 2.0 shipped with Visual Studio 2005. I use quotes because various service packs have been applied along the way but the CLR can still be thought of as version 2.0.
Windows Vista shipped with .NET Framework V3.0 and the CLR “stayed the same”. We just got new libraries for WPF, WCF, WF, CardSpace.
Visual Studio 2008 shipped with .NET Framework V3.5 and the CLR “stayed the same” again. We got new libraries for things like LINQ and lots of other features. Those features went into new assemblies so as to avoid having to alter existing ones.
Visual Studio 2008 Service Pack 1 shipped with .NET Framework V3.5 Service Pack 1 and the CLR “stayed the same” again. We got new libraries for things like Entity Framework, ADO.NET Data Services and so on.
With Visual Studio 2010 and .NET Framework V4.0 things change. There’s a new CLR. If you want to know what’s “new” about the CLR then take a look at this session here from the PDC 2008;
with one of the key features being that we’ll be able to have components built on one CLR in-process with components from another CLR and that won’t break applications which is important if you write code for “add-in” environments like Office or the Windows Shell where you don’t explicitly load the CLR yourself but, instead, it’s automatically loaded for you on-demand and the first CLR loaded used to “win” prior to .NET 4.0.
Now, with all of that said, there’s one thing I’d missed about the V4.0 bits which I thought was worth sharing as it surprised me.
A customer prompted it with a question the other day;
“If we have existing applications built against .NET 3.5 Service Pack 1 and new ones built against .NET 4.0 and we just deploy the .NET 4.0 installation package, will our 3.5 Service Pack 1 applications run ok on that?”
Now, I knew that you can’t just take a 3.5 Service Pack 1 application and run it on the V4.0 CLR. It needs a V2.0 CLR or reconfiguring with a <supportedRuntimes/> tag in order to bend the application to run on the V4.0 CLR and that bending might be something that you don’t want to do.
What I hadn’t realised though was that installing .NET 4.0 wouldn’t install the bits that you need for a 2.0/3.0/3.5/3.5Sp1 application. It would only install the V4.0 CLR and the V4.0 assemblies and not additionally install the equivalent of .NET Framework V3.5 Sp1. So, you’d need to install (e.g.) .NET Framework V3.5 Sp1 yourself along with .NET 4.0.
Worth bearing in mind if it impacts on your deployments – I checked this today and got confirmation but let me know if I’ve got something wrong and I’ll update the post.