Support Ending for the .NET Framework 4, 4.5 and 4.5.1

As previously announced, starting January 12, 2016 Microsoft will no longer provide security updates, technical support or hotfixes for .NET 4, 4.5, and 4.5.1 frameworks. All other framework versions, including 3.5, 4.5.2, 4.6 and 4.6.1, will be supported for the duration of their established lifecycle. The decision to end support for these versions will allow us to invest more resources towards improvements of the .NET Framework.

What Does This Mean?

You should ensure that a supported version of the .NET Framework is installed in your environment, on Windows desktops and servers. This includes Azure and other cloud service deployments. See more information on Azure deployments below.

Applications targeting a .NET Framework version that is no longer supported will not need to retarget or recompile to a newer version as they can be run on a later .NET Framework version. The .NET Framework 4.5.2 and higher versions have higher compatibility, provided by a newer feature called “quirking”. Quirking is a pattern in which a .NET Framework version maintains the semantics of earlier versions, while including updated implementations. The .NET runtime knows which of these semantics or quirks to execute depending on the .NET Framework version that the application targets. More information on migrating an application can be found on the Migration Guide to the .NET Framework MSDN article.

The Azure team announced they will be making updated images available with the .NET Framework 4.5.2 for guest OS families 2.x, 3.x and 4.x, in order to support apps deployed to Azure. These updated images were available for manual deployment in November and are available for automatic deployment in January. The Additional Information section below has more information.

Validate the .NET Framework Version(s) Currently Installed

Multiple versions of the .NET framework can be installed on a machine. The registry can be used to determine if the .NET Framework version 4.5.2 or later has been installed. You will need administrative credentials to read the registry with regedit.

From the Start menu, choose Run

In the Open box, enter regedit

In the Registry Editor, open the following subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\FullNote: If the Full subkey is not present, then you do not have the .NET Framework 4.5 or later installed.

Check for a DWORD value named Release which indicates which version of the .NET framework is installed.

Will I need to recompile/rebuild my applications to make use of .NET 4.5.2, 4.6 or 4.6.1?

.NET 4.5.2, 4.6 and 4.6.1 are compatible, in-place updates 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 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.

More information about application compatibility across the various versions in the .NET 4.x family can be found here.

Microsoft products such as Exchange 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, Dynamics CRM, Sharepoint, and Lync are based on the .NET 4 or .NET 4.5. Even a large software application such as Exchange that was built using .NET 4 will continue to run without any changes when it runs on .NET 4.5.2 or later. That said, we recommend you validate your deployment by updating .NET to .NET 4.5.2 in a QA/pre-production environment first before rolling this out to a production environment.

How will I get this update in Windows Azure Guest operation system (Guest OS)?

On November 10, 2015 Azure announced that they will update the .NET Framework in Windows Azure Guest operating system (Guest OS) family 2.x, 3.x and 4.x to .NET Framework 4.5.2 in the January 2016 Guest OS Release. Cloud services running on Guest OS family 2.x, 3.x and 4.x with automatic updates enabled will be updated to the January 2016 Guest OS with .NET Framework 4.5.2. In order to help customers validate their cloud service with .NET 4.5.2, Azure will provide a second set of November OS Versions 201511-02 for with .NET 4.5.2 for manual deployment. If you have any questions or require further information, please use one of the support options to contact Azure.

What about .NET 3.5 SP1? Is that no longer available?

This announcement does not affect versions prior to .NET 4. You can continue to use .NET 3.5 SP1 beyond January 12, 2016.

If you consider 4.5.1 and 4.5.2 more like SPs, like we used to ship, then this matches our existing policies. The additions in 4.5.1 and 4.5.2 were relatively minimal. 4.6 was a bigger release, for example.

@WinUser – You are correct. Those apps will run under 4.5.2 or later, including 4.6.1. There are multiple ways to describe this situation. We decided to go with the simplest approach, which was to describe 4.5.2 as the upgrade target since it's the closest version to the versions going out of support. It's great if folks want to upgrade past 4.5.2 to 4.6 or 4.6.1.

I would definitely avoid .NET 4.6 where as 4.6.1 is fine. .NET 4.6 is severely buggy in terms of JIT and garbage collector. Microsoft should encourage people to move .NET 4.6.1 instead and drop support for 4.6 as well.

…That said, we recommend you validate your deployment by updating .NET to .NET 4.5.2 in a QA/pre-production environment first before rolling this out to a production environment …

That means to me: deploy, test and if you notice a problem then that will be yours.

The fact is, there are breaking changes between .net 4.5 an the current version 4.6.1 and no one can guarantee that my EDI, B2B, … solution will work. (Otherwise there were no need of testing)

That will be at least time consuming!

As long as supported versions of BizTalk, SharePoint, Exchange and other products of Microsoft are using .NET 4.5, it should be supported also, or at least Microsoft should provide CUs, SPs, … which provide fully transparent support of .net 4.6.1 and not saying test it by your own.. that’s not our problem! That is ridiculous.

Shoudn't the compatibility between DNX 4.5.1 and .Net 4.5.1 be maintained. After all, base development on 4.5.1 .net code can be ported over to DNX 4.5.1 with no problem. I recommend holding off until we get a DNX 4.6, etc.

Microsoft would be better off moving toward a single .NET framework for ONLY it's C# product so it can compete more easily against Java.

The appeal of Java is you download a JDK, NetBeans, Eclipse, JEdit, or some other similar product and you are up and running knocking the bottom out of it.

Microsoft can do the same with C#, C/C++ and visual studio if it would eliminate all the extra junk it creates.

it should kick VB, J#, and F# to the curb and eliminate them entirely.

It should then begin to make it's C/C++ product more in line with UNIX/LINUX/POSIX libraries, standards, etc. and quit making it so difficult for folks to run standard C/C++ on a windows platform and a linux platform. It's not a problem having to have two compilers if the baseline code doesn't have to make all kinds of #ifdef statements because Microsoft didn't use the same library naming conventions (whose dumb idea was that anyway?)

F the CLI for C/C++ too. If you are going to write C/C++ code you don't want the overhead created by the CLI, .NET etc. We choose to write C/C++ for performance reasons.

Focus on C# and C/C++ and quit being distracted by all the other junk.

Folks like me also write python, Ada, and anything else that comes along. We like to be able to switch between languages, targets, and tools without wasting time dealing with mismatched software stacks and PhD dissertations/research that somehow made it into production without any industry validation.

Well, all I can say is that the same things that you see as Microsoft offloading responsibility, I see as common sense or similar things.

The whole testing of BizTalk on 4.5.2 could be seen in the way you see it, but then again, this is the problems with taking parts of statements out of context. The full statement was:

"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 any

changes 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."

Things utterly change there, because there is now the assurance that it should continue working unmodified. So why would they need to add the recommendation to test things out? Well, besides being standard business practice, making sure that an update doesn't take down your critical services, there are still two possibilities.

First, an unexpected bug in your own code being inserted into these servers, (BizTalk allows .NET assemblies written by you). Secondly, an unexpected bug in the framework itself. But the .NET framework point releases are supported based on them essentially being service packs, and the requirements for BizTalk calls that exact situation out.

For .NET 4.6, yes, that is a totally unsupported situation. So there is no guarantee between 4.5.x and 4.6.x simply because BizTalk server explicitly states that it is only supposed to run on any of the 4.5.x variants of .NET. This whole article is saying that 4.5 is still being supported by Microsoft, but only in 4.5.2, which by their own requirements for BizTalk is fully supported.

I suspect that some are confused as to what this means for their particular software builds.

I do not work for Microsoft, but I am a release engineer for a software company in Rhode Island, USA.

Existing applications compiled using .NET Framework 4 will still work, even if you include a newer version of .NET Framework in your software package. For instance our application is compiled under .NET Framework 4 because we are still using VS2010. However one of our third party files requires .NET Framework 4.5.1. I chose to include 4.5.2 with our application. Our application which is compiled to target .NET Framework 4.0 still works with 4.5.2 because .NET Framework itself is backward compatible to 4.0. We do not have to do anything special or new to our application to make it work with newer versions of .NET Framework.

For those of you who are wondering why MS is still supporting .NET Framework 3.5 sp1, it is because it is tied to a different 2.0 core. All the .NET Framework versions from 4.0 and newer are tied to the 4.0 core.

If you are an administrator responsible for deploying software within a company environment, for you this means that you should upgrade to 4.6.1, first in your test environment to ensure there are not any complications of this change, and then to production. All applications compiled for .NET 4.0 and newer will work with 4.6.1.

For those of you referencing products like BizTalk, you can still compile with current requirements for .NET 4.5. You code will still work with systems that have a newer version of .NET Framework.

Hopefully this helps clarify what this change means. For us we will continue to compile targeting 4.0 and deploying 4.5.2 .NET Framework.

For your complaint at C/C++, which standard are you talking about anyway. VC2015 is getting quite far along with the ISO C++ standard, and they have also started working on support for the Clang frontend. So the standard C++ conformance is quite high.

If you are talking about posix, then I would suggest you start working on the time machine needed to even hope to change this. Posix 1.0 was first defined in 1988 according to Wikipedia, the Windows 16 bit API that the current API is based upon actually came before that. Windows NT, which was the first real implementation of the Win32 API was released in 1993, but it was in development since 1988. So from those dates, it is easy enough to see that posix really wasn't enough of a thing back then, and Microsoft also attempted to keep compatibility with their own 16 bit API that had been in usage since before posix 1 was even standardised.

It would be nice if, short of the ideal solution of moving to semantic versioning, if you could include an additional attribute in the registry to identify the intalled version by a moniker instead of only having the build number.

There have been several comments about the need for validation of the .NET Framework 4.5.2 (or later). We have tested many configurations of Microsoft and 3rd party software. We have a compat lab of .NET software (from many companies) that gets tested frequently, particularly before we ship a new version, like the .NET Framework 4.6.1. As an aside, we do accept new additions to our compat lab. You can email netfxcompat@microsoft.com to discuss getting your software added.

Many of you run .NET in critical production scenarios. Any time you make a significant update to those production systems, we recommend testing those updates first. Certainly, upgrading the OS would be considered a major update. Upgrading the .NET Framework is also a significant update for a critical production system. It's just good practice to ensure that the system continues to function as expected when you make a significant system-level change. Most of the time, everything will work great, but it's good to know that ahead of time. There are sometimes unexpected issues.

In terms of upgrading, I would recommend either 4.5.2 or 4.6.1. @onurg points this out, too, earlier in the comments (on page 1). Many customers have upgraded to those families (4.5.x and 4.6.x) of releases, and their feedback is now implemented in the .1 or .2 version of the product. Most of those fixes are for niche scenarios, but it is good to know that they are there, since they typically affect more than one customer.

We've been shipping releases more frequently the last few years. We believe that it is highly valuable to have a "rollup release" of fixes (e.g. 4.6.1) that you can install as a single action, instead of installing a .0 version and waiting for patches to come down from Windows Update.

We have a big team at Microsoft working on .NET. In fact, we actually have multiple big teams working on .NET. The investment from Microsoft in open source .NET Core has increased since it went open source. Honest question … have you looked at the level of activity on our open source repos at https://github.com/dotnet? It's pretty high and something we're frankly proud of. The community response from fortune 500 to mom and pop shops to university students has been overwhelmingly positive. We've had many people just stop to say "thank you" and leave it at that. Nice.

On the .NET Framework, we're committed to both future development and servicing releases of the product. We're going through a planning phase right now for the next version, either 4.6.2 or 4.7. We've been deprecating Service Packs for over a decade. That's nothing new. The thing that may be new is that we're increasing our transparency. This is actually the second post on this topic. Deprecating older releases is something that do to make us more efficient. It enables us to focus more energy on future releases.

We've also been posting on our servicing updates for a while. It's another change for greater transparency. See: blogs.msdn.com/…/servicing.

Would love to hear if our readers find this increased transparency valuable.

The registry check above doesn't appear to work correctly. I checked and my pc is missing the "Full" key but when I try to install 4.5.2, I get a warning to say that 4.5.2 or a later version is already installed.

@Brian – The versioning for .NET framework from .NET 4.5 onwards is identified by a unique release key value. Each time we ship a newer version of the framework the release key associated with the framework is published on MSDN @ msdn.microsoft.com/…/hh925568(v=vs.110).aspx. The release key value makes it simpler to have detection checks as needed and enables having a forward compatible detection check via >= checks. Details on this is @ msdn.microsoft.com/…/hh925568(v=vs.110).aspx

@Preeti – Understood and I fully support having an identifier suitable to programmatic consumption. But no one calls it that. We say .NET 4.6.1, etc. I'd like to have an additional token to reflect the release name in the common tongue, akin to what appears in the righthand table column in the well-known post you reference (which is the exact post I'm used to having to first google to find, then pull up in order to look up the corresponding value to then dereference…an even better option would be to make a utility like dotnetver part of the standard distribution).

@Eugene – Azure will update the .NET Framework in Azure Guest operating system (Guest OS) family 2.x, 3.x and 4.x to .NET Framework 4.5.2 in the January 2016 Guest OS Release. Cloud services running on Guest OS family 2.x, 3.x and 4.x with automatic updates enabled will be updated to the January 2016 Guest OS with .NET Framework 4.5.2. You can find more information on the Azure Guest OS Releases and SDK Compatibility Matrix page (azure.microsoft.com/…/cloud-services-guestos-update-matrix).

How can you remove support to older version when currently (December 15th) .NET framework 4.6 or 4.61 have multiple installation problems. It is not responsible to force customers to use software that is not fully working. After 20 years of working with Microsoft applications I have never seen such a careless decision.

As announced by Microsoft that they are not going to release any security updates for .net 4.0 any more. Does that mean that if we use any obsolete members (msdn.microsoft.com/…/hh419161(v=vs.110).aspx) in our code and compile with .net 4.6.1 there will be any security vulnerability?

As announced by Microsoft that they are not going to release any security updates for .net 4.0 anymore. Does that mean that if we use any obsolete members (msdn.microsoft.com/…/hh419161(v=vs.110).aspx) in our code and compile with .net 4.6.1 there will be any security vulnerability?

I am just going to ask point blank here. After reading comments, I am getting this message (please let me know if I misunderstood) .

1. You don't need to recompile to target 4.5.2 or higher

2. As long as you have the framework installed on desktops and servers

you will be supported when you call Microsoft?

is that correct?

so if my target framework is 4.0 but I deploy .Net 4.5.2. let say we have some issue with the app. then I need some support from Microsoft. I call Microsoft. what will they say? will they say. change your target framework first? or they will help me with my issue? let say the issue later turns out nothing to do with .net framework?

what does it really mean for us when it says "support ending for 4.5.1"?

If you create a SharePoint solution/project in Visual Studio their is NO option to set them to use a higher version than 4.5. If you install SharePoint the installer fails if you have 4.6 installed. It’s not your fault… but it is strange…

I have a software that is targeting to .NET Framework 4.0. After I installed .NET Framework 4.6.1, The software shows some columns that was hidden when I have .NET Framework 4.0.Then I tried to install 4.0, but it didn’t allow me to do that, and it said “a later version is installed”.

My question is :
1, it said a computer can install multiple versions of .NET Framework, why couldn’t I install 4.0 after i have already installed 4.6.1?
2, it said “NET 4.6.1 is compatible, in-place updates on top of .NET 4,… “, why the hidden columns are shown after I installed 4.6.1?

Updating to a supported version of the Framework doesn’t mean that the older versions are gone; so what do you do, if you’re audited and flagged for having an unsupported version of the Frameworks?

Current situation, Winders Server 2012R2 comes with Frameworks 4.5.1 installed out of the box. I update to v4.6.1 and provide software solutions targeting v4.6.1, but I am still flagged as having 4.5.1 on the machine. Work around? Or am I resolved to having to upgrade to Windows 10?

– I have a problem with my .NET v4.5.2 version installed on my Win 7 SP 1system. When I search the registry then is says “Release 379893”. That does suggest/indicate that I have version v4.5.2 installed. So far, so good.
-But it seems that Windows and/or Windows Update doesn’t recognize I have v4.5.2 installed. Because when I installed the March 2017 Security & Quality Rollup Update then my system reports that NET version v4.6 has been installed. And that’s extremely “curious” because according to this article Microsoft still supports NET version v4.5.2.