.NET support for Windows 7 and 8.1 will end in January 2023

[richlander]

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

[huoyaoyuan]

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.

[John0King]

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!

[richlander]

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.

[John0King]

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 .

[richlander]

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.

[huoyaoyuan]

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.

[jkotas]

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.

[jkotas]

Note that we are deleting the support for other OSes that are EOL too. For example, dotnet/runtime#60138 .

[richlander]

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.

[Genbox]

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?

[AaronRobinsonMSFT]

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.

[Genbox]

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

[richlander]

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.

[John0King]

@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?

[richlander]

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.

[richlander]

FYI on Microsoft Office: https://docs.microsoft.com/en-us/deployoffice/endofsupport/windows-7-support

[richlander]

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

[John0King]

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.

[richlander]

It's very likely that no other platform has as rich of a Windows implementation as .NET.

[PathogenDavid]

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.

[richlander]

The team will mostly link to this issue. It should be straightforward to track.

[ericmutta]

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 👍

[agocke]

@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

[John0King]

@agocke

no matter who contribute on it , it even work on win xp !

[fitdev]

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?

[vcsjones]

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.

[fitdev]

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?

[jkotas]

However, in reality, we all know that edge supports Windows 7.

It is not what the official support statement for Edge says. There is a difference between "supported" and "still works".

[RockNHawk]

I'm aware that official support for Windows 7 ended with .NET 7, I have to keep my project using .NET6.

I attempted to publish it with .NET 7 from an enterprise application, but it didn't run on Windows 7.

Can the community provide any assistance in making it compatible with Windows 7?

@jkotas @richlander @John0King

[EatonZ]

@RockNHawk If your app worked fine with .NET 6 on Windows 7 there shouldn't be any problems with .NET 7. It's worked perfectly fine for me. Please elaborate on what you mean by "didn't run". Is an error shown? Silent crash? Check the Application event log for more clues too.

[RockNHawk]

@RockNHawk If your app worked fine with .NET 6 on Windows 7 there shouldn't be any problems with .NET 7. It's worked perfectly fine for me. Please elaborate on what you mean by "didn't run". Is an error shown? Silent crash? Check the Application event log for more clues too.

Wow, .NET 7 works fine on Windows 7 for you ??

Unfortunately, I was prompted that API-ms-win-crt-run-time L1-1-0-0.dll was missing, and I have tried folling fix:

I picked up all api-ms-*.dll from the .NET 6's app self contained distribution, copy these dll files into the .NET 7 version directory.

Retry run app, but got the following error:

(the api-ms-*.dll list from .NET 6 application self contained folder I copied to .NET 7 folder)

Unable to find entry point, unable to locate program input point UCRTBASE, . Noinfo. The dynamic link library api-ms-win-ct-runtime-1-l-0. DLL on.

Note: Windows 7 sp1 x64, the .NET 6 works well, and I have tried publish a very
simple ASP.NET Core app with .NET 7 with the same error

[huoyaoyuan]

Unfortunately, I was prompted that API-ms-win-crt-run-time L1-1-0-0.dll was missing

The UCRT dlls should already be required for .NET 6. They were unnecessarily included in .NET 6, and removed in .NET 7.

The .NET 6 support on Windows 7 already indicates UCRT:
https://learn.microsoft.com/en-us/dotnet/core/install/windows?tabs=net60#additional-deps
You should be able to find the api-ms-* files in system32.

When talking about Windows 7 support, we are always referring to the final version with all updates installed.

[RockNHawk]

Unfortunately, I was prompted that API-ms-win-crt-run-time L1-1-0-0.dll was missing

The UCRT dlls should already be required for .NET 6. They were unnecessarily included in .NET 6, and removed in .NET 7.

The .NET 6 support on Windows 7 already indicates UCRT: https://learn.microsoft.com/en-us/dotnet/core/install/windows?tabs=net60#additional-deps You should be able to find the api-ms-* files in system32.

When talking about Windows 7 support, we are always referring to the final version with all updates installed.

Yeah, But I'm trying using .NET 7 on Windows 7, not .NET 6.

[RockNHawk]

Unfortunately, I was prompted that API-ms-win-crt-run-time L1-1-0-0.dll was missing

The UCRT dlls should already be required for .NET 6. They were unnecessarily included in .NET 6, and removed in .NET 7.

The .NET 6 support on Windows 7 already indicates UCRT: https://learn.microsoft.com/en-us/dotnet/core/install/windows?tabs=net60#additional-deps You should be able to find the api-ms-* files in system32.

When talking about Windows 7 support, we are always referring to the final version with all updates installed.

Have you tried running .NET 7 or .NET 8 on Windows 7, does it works ？

[EatonZ]

@RockNHawk Try installing the latest C++ runtimes:

• https://aka.ms/vs/17/release/vc_redist.x64.exe
• https://aka.ms/vs/17/release/vc_redist.x86.exe

Install both.

[RockNHawk]

@RockNHawk Try installing the latest C++ runtimes:

• https://aka.ms/vs/17/release/vc_redist.x64.exe
• https://aka.ms/vs/17/release/vc_redist.x86.exe

Install both.

Cool, it works. Thank you for your information, I can use .NET 7 event maybe .NET 8 on windows 7.
Great!

[Sin-Shadow-Fox]

HI. I'm a windows 7 user and I'm trying to figure out what version of .NET to install. I keep coming across different answers from 3 to 7, maybe even 8. I'm not very tech savvy and before today i didn't even know what .NET was (I still don't, i just know i need it to install games through Steam's console). I have windows 7 Home Premium 6.1 (Build 7601: Service Pack 1) x64

[EatonZ]

@Sin-Shadow-Fox Each software has its own .NET version requirement. In the context of this issue, I have found everything up to .NET 8 to work fine on Windows 7, but do note that the software that utilizes it may not actually be Windows 7 compatible anymore. This is more of a question for the developer(s) of the software you are using.

[Sin-Shadow-Fox]

@Sin-Shadow-Fox Each software has its own .NET version requirement. In the context of this issue, I have found everything up to .NET 8 to work fine on Windows 7, but do note that the software that utilizes it may not actually be Windows 7 compatible anymore. This is more of a question for the developer(s) of the software you are using.

How do i contact them?

[EatonZ]

@Sin-Shadow-Fox Whoever makes the .NET executable you are trying to launch, they are the ones you need to reach out to.

[Sin-Shadow-Fox]

@Sin-Shadow-Fox Whoever makes the .NET executable you are trying to launch, they are the ones you need to reach out to.

I don't know who makes .NET.

[EatonZ]

@Sin-Shadow-Fox Microsoft makes .NET, but application developers use .NET to build their apps.
Whoever made the app you are using are the ones you need to get in touch with.

[Sin-Shadow-Fox]

@Sin-Shadow-Fox Microsoft makes .NET, but application developers use .NET to build their apps. Whoever made the app you are using are the ones you need to get in touch with.

I guess that might be Steam/Valve but the only way to contact them is through their ticket system which is notorious for being unhelpful. Is there another way?

[EatonZ]

@Sin-Shadow-Fox If the problem is with a Steam component, you are out of luck in this case because Steam dropped support for Windows 7 a few months ago: https://help.steampowered.com/en/faqs/view/4784-4F2B-1321-800A

Time to upgrade. 🙂

[Sin-Shadow-Fox]

@Sin-Shadow-Fox If the problem is with a Steam component, you are out of luck in this case because Steam dropped support for Windows 7 a few months ago: https://help.steampowered.com/en/faqs/view/4784-4F2B-1321-800A

Time to upgrade. 🙂

Unfortunately there is not a viable upgrade to windows 7 in the windows OS chain yet (and i really don't want to move to linux). Fortunately however, thanks to windows 7 users putting our Steam clients into offline mode before the shutoff, Steam still works perfectly fine I'm happy to report. However in order to use the Steam console, i need to have .NET installed https://steamcommunity.com/sharedfiles/filedetails/?id=2353930763

[EatonZ]

@Sin-Shadow-Fox Ok, it's not clear what .NET version you will need, but just install all these and it should hopefully take care of the issue:

1. https://aka.ms/dotnet/8.0/windowsdesktop-runtime-win-x64.exe
2. https://aka.ms/dotnet/7.0/windowsdesktop-runtime-win-x64.exe
3. https://aka.ms/dotnet/6.0/windowsdesktop-runtime-win-x64.exe
4. https://aka.ms/dotnet/5.0/windowsdesktop-runtime-win-x64.exe

[Sin-Shadow-Fox]

@Sin-Shadow-Fox Ok, it's not clear what .NET version you will need, but just install all these and it should hopefully take care of the issue:

1. https://aka.ms/dotnet/8.0/windowsdesktop-runtime-win-x64.exe

2. https://aka.ms/dotnet/7.0/windowsdesktop-runtime-win-x64.exe

3. https://aka.ms/dotnet/6.0/windowsdesktop-runtime-win-x64.exe

4. https://aka.ms/dotnet/5.0/windowsdesktop-runtime-win-x64.exe

Doesn't having several different versions of the same program running at the same time create issues?

[EatonZ]

@Sin-Shadow-Fox In this case there is nothing to worry about. Of course, you can go through 1-by-1 to figure out what is actually needed, and only keep that one installed.

[hamarb123]

Each release version of .NET can be installed side-by-side, and furthermore, if an app is built for .NET 7, it won't run unless you have 7 installed (usually), even if you have 8 installed.

[Sin-Shadow-Fox]

@Sin-Shadow-Fox In this case there is nothing to worry about. Of course, you can go through 1-by-1 to figure out what is actually needed, and only keep that one installed.

So i ended having to install all 4 that you provided and . . .

Each release version of .NET can be installed side-by-side, and furthermore, if an app is built for .NET 7, it won't run unless you have 7 installed (usually), even if you have 8 installed.

Then doesn't that mean i should technically install every version of .NET?

[agocke]

@Sin-Shadow-Fox you should ask your questions to the developers of the DepotDownloader tool https://github.com/SteamRE/DepotDownloader