Il .NET Framework 4.5 è rilasciato come un in-place upgrade della versione 4.0. Questo significa che .NET 4.5 sostituisce completamente la release precedente sul PC, senza modificarne il numero di versione. Come si può leggere nel post .NET 4.5 is an in-place replacement for .NET 4.0 di Rick Strahl:
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 4.5 update completely replaces the .NET 4.0 runtime and leaves the actual version number set at v4.0.30319.
Un punto che può creare confusione riguarda la possibilità di creare applicazioni per .NET 4.0 dopo che è stato effettuato l'upgrade alla versione 4.5. Rick ci dice che:
When you build a new project with Visual Studio 2011, you can still target .NET 4.0 or you can target .NET 4.5. But you are in effect referencing the same set of assemblies for both regardless which version you use.
Scott Hanselman, invece, nel suo post .NET Versioning and Multi-Targeting - .NET 4.5 is an in-place upgrade to .NET 4.0, fa notare una cosa diversa:
It's been implied on blogs that if you install .NET 4.5 on your machine that you can't safely develop for .NET 4. In Rick's post, he compares two DLLs on a .NET 4 machine and again after the .NET 4.5 in place upgrade. How can you target safely against .NET 4 if you've installed .NET 4.5? You don't have those .NET 4 DLLs anymore, right?
Actually you do. They are in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework.
[…] So while .NET 4 and .NET 4.5 don't live side by side on your system at runtime, Visual Studio knows about all the different versions of .NET and the compiler will reference different versions when you build.
Chi ha ragione? La cosa necessità di ulteriori approfondimenti.