core
core copied to clipboard
dotnet
.NET support for Windows 7 and 8.1 will end in January 2023
.NET support for Windows 7 and 8.1 will end in January 2023
Windows 7 and Windows 8.1 are currently supported with .NET 6. They will not be supported with .NET 7+.
Windows 7 is only supported (with .NET 6) for organizations that have purchased Extended Security Updates (ESU). Windows 7 will be supported for those organizations until the ESU offering ends, which is January, 2023. At that time, Windows 7 will no longer be supported with .NET 6.
Windows 8.1 is supported until January 2023. At that time, Windows 8.1 will no longer be supported with .NET 6.
Windows Server 2012/R2 ESU will start mid-way through the .NET 7 lifecycle, in October 2023. We will offer support for Windows Server 2012/R2 throughout .NET 7 and .NET 8, assuming you have purchased ESU updates. We recommend that you do not install .NET 7 on Windows Server 2012/R2 unless you have a migration plan (within a year of .NET 7 General Availability) to a newer operating system or plan to purchase Windows Server ESU.
Windows Server 2016+ will be supported throughout .NET 7 and .NET 8.
We encourage you to migrate to Windows 10 or 11 if you would like to use .NET 7 or later on Windows Client.
Will code for these OS deleted? Given that a lot of people still use unsupported OS, application authors often support as much OS as they can.
MS can't wait to killing Win7/win8 ? People want to use C# as a programming language , but MS mke it to be a product!
Will code for these OS deleted?
For the .NET 6 servicing branch, absolutely not. For .NET 7 (main), TBD. Once main switches to .NET 8, very likely.
MS can't wait ...
We didn't review this plan with the Windows team. We looked at the same published dates you have access to (the ones I linked to) and did a reasonable analysis of them to come to this plan.
We don't support OS versions past their due date. There are only two cases where we have supported an OS version for an extended period: Windows 7 and Ubuntu 16.04. I'm certain the same thing will happen with each Ubuntu LTS. Turns out Ubuntu is popular. Who knew? Our approach is actually pretty principled, documented, and consistent. It's also not biased to Windows. It's definitely biased to customer usage patterns.
We don't support OS versions past their due date.
This decision will not help MS to selling new windows, but do help developers to leave MS product!
Is there any win7 stuff stop your team to develop new .net version ? if there not or only a little , why drop the support so quikly when no other { product from other company / programming languages / platfroms } do that .
It's very likely that .NET 6 will continue to function the same/correctly on Windows 7 past this date. We're NOT going to do anything intentional to prevent that. There are no builds we are turning off. Windows 7/10/11 are one binary build, as demonstrated by our website.
The effective change is that companies won't be able to call Microsoft for support anymore for .NET 6 on Windows 7 to seek a fix to whatever problem they have. I don't know if the other examples you are thinking about have an organization like Microsoft Support to help their users. If not, the comparison doesn't cleanly apply.
I think it's better to claim it as "works but unsupported". As an open source project, there will still be chances for community members to fix problems specific to Windows 7.
Currently there are only 5 uses of Environment.IsWindows8OrAbove in corelib. For NT6 I don't expect there to be much hard problems. And unlike .NET Framework, .NET Core isn't integrated into OS.
Currently there are only 5 uses of Environment.IsWindows8OrAbove in corelib.
There are more than hundred places where we have workarounds for Windows 7 (most of them are in tests).
I expect that once we turn off the Windows 7 testing, it is going to regress pretty quickly. I do not expect that the community will be interested in nor able to keep up with these regression.
Note that we are deleting the support for other OSes that are EOL too. For example, https://github.com/dotnet/runtime/issues/60138 .
When we remove support for Windows 7, we'll be deleting the support for it from the codebase. That's our policy and it will make us more efficient. We haven't decided if this deletion will be in the .NET 7 or 8 tree. It's likely that .NET 6 will work on Windows 7 forever, but will (obviously) be unsupported.
There are more than hundred places where we have workarounds for Windows 7 (most of them are in tests).
Is there a way to identify these places?
One way is to look for uses of https://github.com/dotnet/runtime/blob/99e58d55c1f02e242f9cbe298d4f31b1a1563207/src/tests/Common/CoreCLRTestLibrary/Utilities.cs#L70
The next would be https://github.com/dotnet/runtime/blob/99e58d55c1f02e242f9cbe298d4f31b1a1563207/src/libraries/Common/tests/TestUtilities/System/PlatformDetection.Windows.cs#L23
There are likely others involved #defines and other tricks. Searching for various sequences involving "win", "windows", and "7" would be the place to start.
Note that we are deleting the support for other OSes that are EOL too. For example, dotnet/runtime#60138 .
Note that 10.13 (High Sierra) and 10.14 (Mojave) today account for 10% of macOS users. Likewise, Windows 7 and 8.1 account for about 16% of Windows users.
I'm not saying it is good or bad. It is just data in case anyone is wondering about the potential impact.
Source: Statcounter
Good info @Genbox. Data is always good.
I want to make a more general observation ... let's say you have an app and you want to sell it to or support in Windows 7. That's great. We're not going to block you from doing that. Do what you need to do.
However, you already have to accept that the Windows team is not supporting your users on Windows 7. Your users are not receiving patches for security, crashes, timezone updates, or new hardware. Why is is such a big deal that the .NET team won't support them either? It's a much bigger deal that the operating system isn't supported. To my mind, it is incongruent to expect the .NET Team to continue supporting .NET (in a given environment) when the more foundational operating system is already end-of-life. You should just accept that the environment isn't getting any more care and feeding.
Again, we're NOT going to add blocks on .NET 6 to stop it working on Windows 7. Doing so would be mean and very unfriendly. .NET 6 should work fine (in an unsupported configuration) on Windows 7 well into the future.
@richlander we are accept it if that means the support of "Microsoft Help" EOL. but it isn't , you are asking developer to stay on old version of .net (but asking community contribute to new version of .net), because the developer's company have to support theire product on customer's computer. and that even a problem for MS self, Teams, Skype and many more product are switch to nodejs/C++/go. just because it can both have the latest the dev env and support more wide range of windows version.
We want our programe to be able to run ANYWHERE! We want .NET to be able to run ANYWHERE! (just like native lanauges like C/C++/ go/rust).
you are already work a lot to make .net to able to run on win7, why those work suddenly became burden?
Right. This plan would mean you are stuck on .NET 6 (for Windows 7 scenarios) forever. We did the same thing with .NET Framework 4.0 and Windows XP. .NET Framework 4.5 wasn't supported on Windows XP. People were not happy about it.
Windows 7 usage will continue to drop. I'm sorry, but we're not going to enable new .NET versions to support it.
There are special cases in .NET code and tests for Windows 7. By deleting them, the codebase is simpler and easier to maintain. Also, we can disable our CI legs for Windows 7. That saves money and time. It's a pretty big win for us. It's important for us to drop support for old OSes, since new ones that we need to support keep on coming. It's the only way for us to have a sustainable engineering system.
Other projects will eventually drop Windows 7 support. It won't be the same timeline as us, but they will, for similar reasons as us.
FYI on Microsoft Office: https://docs.microsoft.com/en-us/deployoffice/endofsupport/windows-7-support
FYI: We're going to start accepting changes in .NET 7 that delete Windows 7 functionality, tests and CI legs.
Update:
For .NET 7, we'll leave Win 7 codepaths as-is. We'll revisit for .NET 8. Windows 7 CI will be disabled for .NET 7 and only run for .NET 6,
@AaronRobinsonMSFT @jkotas
Other projects will eventually drop Windows 7 support. It won't be the same timeline as us, but they will, for similar reasons as us.
They will drop win7 as msvc compiler start became a gap or some windows feature became a gap, I don't think any other language will drop OS support because the reason as "Codebase cleanup" .
there is windows notification feature start win8, but electorn app create wrap to fit both win7 and win8+ and even win xp. android create andorid support library or andorid X support library and all of those library can even support andorid 4.4, that's why andorid apps are so many, because there are no break between them.
It's very likely that no other platform has as rich of a Windows implementation as .NET.
Just last week I was talking to a client about how much we wanted to bother with Windows 7 as we transition their app from .NET Framework to modern .NET, so this announcement should make finalizing that decision easier 😅
FYI: We're going to start accepting changes in .NET 7 that delete Windows 7 functionality, tests and CI legs.
If it's not going to mess with workflows too much, could a tag be added for issues/PRs doing this? Maybe goodbye-win7?
It'd be interesting to see the extent this cleans things up over time and might make it easier to appreciate the burden Windows 7 support had on a product as large as .NET.
The team will mostly link to this issue. It should be straightforward to track.
I understand the theory behind this change but in practice it is going to make a lot of people unhappy (and "a lot" here means "more than you could initially imagine").
I have a ten year old laptop that runs Windows 8.1. It is perfectly functional and likely to have a few more years of life in it (Toshiba used to build them good!). My immediate reaction to this announcement was "I won't use .NET 7 then"... because for me, upgrading from .NET 6 means buying a new developer-grade laptop (that's a $2,000+ investment).
So while time marches on and we all eventually have to upgrade, it's important to keep in mind not only the cost for Microsoft to keep supporting old versions, but also the cost of upgrades for the many many more people out there who may have to buy new hardware in order to get new software (rarely a good deal, cost-wise).
My only request is you don't put a constraint on the versions of Visual Studio we can use (e.g. if Visual Studio 2023 comes out and is only supported for .NET 7+ now people who can't use .NET 7 also can't use Visual Studio 2023... which is not going to be nice at all if it happens).
In closing here's an anecdote: I made an accounting system 10yrs ago that runs on .NET 3.5 and uses SQL Server 2008. Just yesterday I made money installing on a customer's laptop with Windows 7. These operating systems just refuse to die and the reason people complain when limitations are enforced is because the decision is actually more financial than technical :+1:
@John0King FYI, Rust's support for Windows 7 is limited to community contributions. There is no CI coverage. https://doc.rust-lang.org/nightly/rustc/platform-support.html#windows-support
After reading though this it is still not clear to me whether .NET 7+ self-hosted app can run on Windows 7, or not? I also think you should make a clearer distinction here on GitHub and in the docs what you mean by "support": do you merely make no guarantees that it will continue to work on an unsupported OS by saying it is not supported, or do you mean that the self-hosted app will simply fail to run in most cases on an unsupported OS.
It is one thing to remove tests pertaining to specific OS or to remove conditionals from code that special-case some very specific areas like Crypto - thus introducing potential issues when an app is run on that OS; while it is another thing when the app simply cannot run due to some serious runtime limitations (like using incompatible native compiler for the native parts, specific guard clauses, etc.). So, which one is it?
I think it's better to claim it as "works but unsupported". ... I don't expect there to be much hard problems
This is not my experience contributing to .NET. Within System.Security, a considerable amount of my effort goes in to supporting Windows 7, or not supporting Windows 7 gracefully. CNG and CAPI2 capabilities and behaviors are quite noticeable between Windows 7, Windows 8, and Windows 10.
I would probably say 1 in 10 pull requests I've done has required special care for Windows 7. Sometimes it's trivial, sometimes it has doubled the amount of effort I've put in to the pull request.
I would agree with @jkotas here - at least for System.Security area, which is heavily dependent on the underlying platform, I would expect Windows 7 behaviors to regress rather soon.
I would agree with @jkotas here - at least for System.Security area, which is heavily dependent on the underlying platform, I would expect Windows 7 behaviors to regress rather soon.
That makes sense. However is there a way for a dev who wants to continue to support Windows 7 for their apps to simply avoid newer APIs that simply have no Windows 7 support and stick to only those APIs that have been in the framework for a long time and hence are supported on Windows 7?
is there a way for a dev who wants to continue to support Windows 7 for their apps to simply avoid newer APIs that simply have no Windows 7 support and stick to only those APIs that have been in the framework for a long time and hence are supported on Windows 7?
I would expect that if Windows 7 compatibility is removed from System.Security, then fairly important things are going to stop working, like hashing. Consider:
https://github.com/dotnet/runtime/blob/0f149b72ae59d40b703ba1c690d8636b99530139/src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/HashProviderCng.cs#L38
We have specific code paths here to handle where Windows 7 does not support reusable hash instances. If this logic were changed and simplified to assuming that hashes are always reusable and BCRYPT_HASH_REUSABLE_FLAG will work, then producing a hash will stop working on Windows 7.
Thank you for pointing this out. But isn't this somewhat of a corner case. What if one was simply using APIs that have existed since .NET 2.0 days or so like just instantiating SHA256 managed version for example, in other words sticking only to APIs that have existed even prior to NetCore days? Why should there be a problem?
This actually, I think, brings another potential large area for .NET Team to consider... Perhaps it is worth attributing public APIs that have OS-Specific logic (in cases where it is not obvious) with a new attribute, similar in spirit to the likes of SupportedOSPlatformAttribute, thus warning devs that use those APIs that in the future such APIs are subject to potentially serious changes when OS/platform support is removed, and thus perhaps they should use double caution when relying on such APIs in their apps?
like just instantiating SHA256 managed version for example
There is no public managed implementation of SHA256 in .NET Core. SHA256Managed is deprecated, and isn't written in managed code anymore. It uses the underlying OS
https://github.com/dotnet/runtime/blob/2a680c1beb7588a100f4f38595b9954683e936a6/src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/SHA256Managed.cs#L22
On Windows, most hashing APIs (with the exception of one shots) will go through the previously linked code.
in other words sticking only to APIs that have existed even prior to NetCore days? Why should there be a problem?
Many existing APIs have logic paths that are explicitly for Windows 7, such as the CNG implementation for hashing and HMAC. As those logic paths get cleaned up to assume "We don't need to support Windows 7 anymore", existing APIs will cease to work on Windows 7.