A first hand look from the .NET engineering teams
A few months ago we announced the availability of the .NET Framework 4.5.2, a highly compatible, in-place update to the .NET 4.x family (.NET 4, 4.5, and 4.5.1). The .NET Framework 4.5.2 was released only a few short months after the release of .NET 4.5.1 and gives you the benefits of the greater stability, reliability, security and performance without any action beyond installing the .NET 4.5.2 update i.e., there is no need to recompile your application to get these benefits.
The quick pace at which we’re evolving and shipping means the latest fixes, features, and innovations are available in the latest version and not in legacy versions. To that end, we are making it easier than ever before for customers to stay current on the .NET Framework 4.x family of products with highly compatible, in-place updates for the .NET 4.x family.
We will continue to fully support .NET 4, .NET 4.5, .NET 4.5.1, and .NET 4.5.2 until January 12, 2016, this includes security updates as well as non-security technical support and hotfixes. Beginning January 12, 2016 only .NET Framework 4.5.2 will continue receiving technical support and security updates. There is no change to the support timelines for any other .NET Framework version, including .NET 3.5 SP1, which will continue to be supported for the duration of the operating system lifecycle.
We will continue to focus on .NET and as we outlined at both TechEd NA and Build earlier in 2014, we are working on a significant set of technologies, features and scenarios that will be part of .NET vNext, our next major release of the .NET Framework coming in 2015.
For more details on the .NET Framework support lifecycle, visit the Microsoft Support Lifecycle site.
If you have any questions regarding compatibility of the .NET Framework you may want to review the .NET Application Compatibility page. Should you have any questions that remain unanswered we’re here to help, you should engage with Microsoft Support through your regular channels for a resolution. Alternatively you can also write to us at netfxcompat_at_microsoft.com.
We have outlined a few Q&A below to help address any questions you may have.
Will I need to recompile/rebuild my applications to make use of .NET 4.5.2?
No, .NET 4.5.2 is a compatible, in-place update on top of .NET 4, .NET 4.5, and .NET 4.5.1. This means that applications built to target any of these previous .NET 4.x versions will continue running on .NET 4.5.2 without change. No recompiling of apps is necessary.
Are there any breaking changes in .NET 4.5.2? Why do you include these changes?
There are a very small number of changes in .NET 4.5.2 that are not fully compatible with earlier .NET versions. We call these runtime changes. We include these changes only when absolutely necessary in the interests of security, in order to comply with industry wide standards, or in order to correct a previous incompatibility within .NET. Additionally, there are a small number of changes included in .NET 4.5.2 that will only be enabled if you choose to recompile your application against .NET 4.5.2; we call these changes retargeting changes.
More information about application compatibility including both .NET runtime and retargeting changes across the various versions in the .NET 4.x family can be found here.
Microsoft products such as Exchange Server, SQL Server, Dynamics CRM, SharePoint, and Lync are built on top of .NET. Do I need to make any updates to these products if they are using .NET 4, 4.5 or 4.5.1?
Newer versions of products such as Exchange, SQL Server, Dynamics CRM, Sharepoint, and Lync are based on the .NET 4 or .NET 4.5. Since .NET 4.5.2 is a compatible, in-place update on top of the .NET 4, 4.5, and 4.5.1 even a large software application such as Exchange that was built using .NET 4 will continue to run without anychanges when the .NET runtime is updated from .NET 4 or .NET 4.5 to .NET 4.5.2. That said we recommend you validate your deployment by updating the .NET runtime to .NET 4.5.2 in a QA/pre-production environment first before rolling this out to a production environment.
What about .NET 3.5 SP1? Is that no longer available?
No, this announcement does not affect versions prior to .NET 4. The .NET 3.5 SP1 version is installed side-by-side with .NET 4.x version, so updates to one do not have impact on the other. You can continue to use .NET 3.5 SP1 beyond January 12, 2016.
Is .NET 4.5.2 available in Azure cloud services and/or websites yet? It can sometimes be tough to determine that without deploying something.
Somewhat unrelated, if you do an Update 4 of Visual Studio 2013, it would be nice to see 4.5.2 bundled in instead of being a separate download.
I'm pretty sure your SharePoint drivers will stop working if it detects its running on .NET 4.5...
I'm confused that .NET 3.5 gets supported beyond 2016-01-12, but not .NET 4.0 (4.0.3), because the latter is the last version that supports Windows XP. Roughly 1/3 of our customers still use Windows XP.
Can an app compiled against 4.5.2 run on a previous 4.x runtime?
We are facing major problem of Out of Memory Exception in .NET4.0 we are not able to find out the root cause of the problem so that we can take corrective measures. Kindly suggest (email@example.com)
I would also like to know if this is supported in Azure and if there is a quick and easy way to work this out in the future.
For the Azure Cloud Services, on the [Azure Guest OS Releases and SDK Compatibility Matrix](msdn.microsoft.com/.../ee924680.aspx) the latest supported .NET version is .NET 4.5.1.
On the [.NET Web Development and Tools Blog](blogs.msdn.com/.../queuebackgroundworkitem-to-reliably-schedule-and-run-long-background-process-in-asp-net.aspx) dated the 4th of June they state they hope to add support for .NET 4.5.2 in cloud services soon.
"3.QueueBackgroundWorkItem (QBWI). This was specifically added to enable ASP.NET apps to reliably run short-lived background tasks. (With some limitations explained at the end of this blog.) As of today, you can’t use QBWI on an Azure Web Site or Cloud Services web role because QBWI requires .Net 4.5.2. We hope to have Azure Web/Cloud running .Net 4.5.2 soon. "
Are there any plans to deploy .NET 4.5.1 as an "important" update in Windows Update? It would be nice if most of our customers have the same (latest) .NET Framework version installed. Otherwise, we have to start testing our client application with different .NET versions (e.g. 4.5; 4.5.1; 4.5.2).
@jer0enh, apps compiled against one version of the .NET Framework can be used against a newer version, but not the reverse. So an app compiled against .NET 4 or .NET 4.5 will run just fine against .NET 4.5.2. An app compiled against .NET 4.5.2 needs .NET 4.5.2 to be present. This makes sense because if we call into a feature only introduced in .NET 4.5.2 then it wouldn't be present in earlier versions.
@Deploy with Windows Update, the .NET Framework 4.5.1 update is already available on Windows Update as a Recommended Update.
@DV Singh, there are many reasons why your application might encounter an OOM, it would be very hard to make recommendations without more information about the specifics about the app. I would recommend you reach out to Microsoft Support and open a case so an escalation engineer can engage with you and help investigate.
When i moved to 4.5 from 4.0 it caused some errors in our web apps which were running fine earlier in classic mode. I had to rollback.
I am still skeptical about trying out 4.5.2 on a production environment!
I guess I'll wait until 5.0!!
i think .NET 5.0 will release great changes and improvement. but when? with Windows 9?
We had an issue with the upgrade from 4.5.1 to 4.5.2 in the way Web API escapes paths with spaces in them. We've had an issue open on connect since May, with a full reproduction (working on 4.5.1, and same code that breaks on 4.5.2) but have not really heard back from anyone.
And what is about .NET 4.5.3? Visual Studio offers this for me as target framework.