.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, https://github.com/dotnet/runtime/issues/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 :+1:

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

[vcsjones]

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.

[fitdev]

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?

[vcsjones]

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.

[huoyaoyuan]

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

Somehow out of topic, but XP lacks really a huge amount of features, for example the Universal C Runtime (UCRT). UCRT on XP was a thing, but requires extra deployment. NT6 was a great change of the OS.

[huoyaoyuan]

Anyway, I think it's too early to actually removing code giving the actual usage amount of Win7. Like the discussion for ARM32(https://github.com/dotnet/runtime/discussions/71042), we should announce and get people prepared first.

[hez2010]

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

Even with C/C++/go/rust, you may still not able to continue shipping your programs to those EOL platforms after several iterations of those compilers, either. The previous example is Windows XP, no compiler is now supporting targeting Windows XP, and Windows 7 will become the next Windows XP.

Actually, all mainstream languages and compilers won't continuously support an end-of-life platform.

[huoyaoyuan]

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

To be fair, .NET ships with a very rich first-party library set. A lot of them depends on OS features, and are trying to abstract over OS differences.

If you don't use the libraries at all, you can even write UEFI boot code with C# (of course with NativeAOT). Getting libraries running is much more work than primitive code.

[Genbox]

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.

@richlander You are right. Everyone wants everything, and they are not the ones that have to maintain a codebase with 7.089.408 LoC of C# (it is the real number for dotnet/runtime btw. calculated it last week), so it is easier for people to complain about it.

There are exceptions though - for example, my company develops an incident response data collection and investigation platform. For obvious reasons, it needs to run on even unsupported versions of Windows, Linux, and Mac, as they are at risk of getting compromised.

We won't be able to upgrade to a newer version of .NET (.NET 7+) for quite some time, but honestly, that is the price of progress. We will handle it just like back when Windows XP support was dropped in the .NET framework 4.0 days.

I suspect developers of desktop apps will be a little bit frighted by this. If they upgrade their app to .NET 7, 16% of their users will be at risk of having unfixable bugs/crashes. However, if I understand the change correctly, Windows 7/8.1 support is a compat hack here and there, and there is a real good chance that whatever functionality the desktop app will be using, does not intersect with the removed features, so it will (probably) continue to work just fine, but without any support from Microsoft or the .NET team. I think that is reasonable.

[richlander]

We're having an internal conversation about. I forgot that Visual Studio uses .NET SDK as well and Visual Studio will soon start using .NET 7 SDK. That's a complication for anyone using Visual Studio 2022 on Windows 7. I don't work on anything related to Visual Studio so I frequently forget about these types of topics.

The current thinking is to revisit removing Windows 7 specific code with .NET 8.

[John0King]

@richlander

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

I don't get it ,why not write them in managed code, people ask more area to be writen in managed code, like JIT and GC,
and managed code have more portability than use OS layer stuff. and I want to post an suggestion for a long time(but hasn't ), it is to put all the OS layer stuff in a top level namesapce eg. Os.Windows.XXX Os.MacOs.xxx , because it should more be consider as an "libraray" instead of the .Net "standard" library(eg. std namespace in C++).

and for the ”System.Security.*“ , writen them in managed code will also eliminate the difference between OSs, make it run anywhere that .net clr run. (also consider it for WASM)

and for the perforamce scenario, those managed algorithms will be a key measurement of the JIT performance.

I know there are some area that must require OS feature, but it work now and why not keep them for tomorrow (before it became real gap bettween OS version)? BTW, "windows LSTS" shows that windows may not have all the feature as it should to be.

[jkotas]

@John0King Rolling your own crypto libraries is incredibly expensive, for both technical reasons (for example, you have to be constantly on top all latest side-channel attacks) and non-technical reasons (for example, you have to deal with FIPS and export controls). We believe that we can get much better ROI by investing elsewhere.

[John0King]

there is an portable native library used anywhere in other language/platform ------ OpenSSL and the that isn't fit, you can build a wrap around an owned native library and use that to calling into OS layer.

anyway, my opinion is that don't let the OS layer cause .net program dotn't run on user machine, make the program that build with .net language run like native language.

If you don't use the libraries at all, you can even write UEFI boot code with C# (of course with NativeAOT)

C# is powerfull , don't let the runtime be a burden of C#

[richlander]

See this Twitter discussion on TLS. It is the same thing.

We already use OpenSSL on Linux, as distributed by the user. We use OS provided APIs on macOS and Linux. Programs that distribute their own copy of OpenSSL need to monitor and reason about OpenSSL CVEs. They will frequently get zero day'd. Admittedly, this is less of a problem for container apps, since rebuild and redistribution is built-in.

Companies that care about FIPS won't ever be able to use crypto libraries written in a managed language.

[John0King]

Companies that care about FIPS won't ever be able to use crypto libraries written in a managed language.

sorry ，I’m not familiar with that. But since .net's System.Security is a an wrap of windows Security library, so move the windows implementation to Os.Windows.Security.* and implement the abstraction in System.Security.* like RSA AES etc. should also be consider acceptable. but the pure managed version will help more people that do not consider FIPS , and also keep your codebase clean.(also help with NativeAOT and WASM) (BTW, https://www.nuget.org/packages/Portable.BouncyCastle look at the download number, that shows how many people do not consider FIPS).

in face System.Security.* is only a small piece on this topic, I think the primary issue is about should .net runtime/sdk be a burden of C#/F# that cause develper's program can't run on users old machine. should MS's .net always be the first platform that giveup on MS's own OS?

[richlander]

This is way off topic. We have no plans to go down the path of a portable crypto library. We are happy to leave that to others.

[fitdev]

@richlander

The current thinking is to revisit removing Windows 7 specific code with .NET 8.

Yes, please move it down to at least .NET 8. Removing it in .NET 7 is way too soon, especially considering how many people actually still use Windows 7! Again, you may of course drop support (as in customer assistance) now, but don't remove critical code that makes it Windows 7 compatible!

In fact, I would argue for a more layered approach: you may remove support (as in assistance) for the older OS-es as well as covering them with specific tests a lot sooner than removing actual code that makes critical areas of the runtime work with them - that code should be removed a few years later. This way it will provide a more realistic and gradual way to handle such things, while also freeing some of your maintenance resources just as you want.

Lastly, perhaps someone on the .NET team can think about addressing this issue holistically (not in regards to just Windows 7) as I suggested above:

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?

[teo-tsirpanis]

That's a complication for anyone using Visual Studio 2022 on Windows 7.

@richlander Visual Studio 2022 requires at least Windows 10.

[EatonZ]

I still have a bunch of users clinging to Windows 7. One more .NET release with Windows 7 support would be appreciated so we can think about convincing these users to upgrade, while also not wanting to miss out on .NET 7 improvements.

I understand wanting to remove all that legacy code too, but unless there is some blocking issue, it seems to make sense to give all that hard work another release before discarding it.

Also, ".NET 7 on Windows 7" just sounds right.😁

[ericmutta]

@richlander The current thinking is to revisit removing Windows 7 specific code with .NET 8.

I think that's a great idea and I hope you and the team approve it! Consider the following two scenarios for adopting .NET 7:

1. People using .NET 6: if .NET 7 reduces operating system support then it is wiser to just stick to .NET 6.
2. People coming from .NET 5 or earlier: they can choose .NET 6 or .NET 7. Since .NET 6 supports more operating systems and is an LTS version, then it is wiser to pick .NET 6 as a baseline.

In both scenarios .NET 6 is the more attractive choice and until .NET 8 comes around, people will keep choosing .NET 6 thus making it even harder to kill when its LTS period runs out. If however, you do NOT drop support for older operating systems, the logic for adopting .NET 7 now becomes:

1. People using .NET 6: .NET 7 supports all the same operating systems and has new features - let's upgrade!
2. People coming from .NET 5 or earlier: .NET 6 and .NET 7 support the same operating systems, so lets pick .NET 7 because it's latest and greatest and it will be easier to upgrade to .NET 8 later.

Essentially, by keeping support for older operating systems in .NET 7, it becomes a no-brainer to adopt .NET 7 and that helps wean more people off .NET 6. When .NET 8 eventually comes out and drops support for those operating systems, there's likely to be some complaint, but at least at that point you'll be upgrading to an LTS release unlike now where choosing .NET 7 would mean losing some operating system support AND jumping on to something without long-term support itself (which is like buying one problem and getting another problem for free :grin:)

[MichalPetryka]

@richlander The current thinking is to revisit removing Windows 7 specific code with .NET 8.

I think that's a great idea and I hope you and the team approve it! Consider the following two scenarios for adopting .NET 7:

1. People using .NET 6: if .NET 7 reduces operating system support then it is wiser to just stick to .NET 6.
2. People coming from .NET 5 or earlier: they can choose .NET 6 or .NET 7. Since .NET 6 supports more operating systems and is an LTS version, then it is wiser to pick .NET 6 as a baseline.

In both scenarios .NET 6 is the more attractive choice and until .NET 8 comes around, people will keep choosing .NET 6 thus making it even harder to kill when its LTS period runs out. If however, you do NOT drop support for older operating systems, the logic for adopting .NET 7 now becomes:

1. People using .NET 6: .NET 7 supports all the same operating systems and has new features - let's upgrade!
2. People coming from .NET 5 or earlier: .NET 6 and .NET 7 support the same operating systems, so lets pick .NET 7 because it's latest and greatest and it will be easier to upgrade to .NET 8 later.

Essentially, by keeping support for older operating systems in .NET 7, it becomes a no-brainer to adopt .NET 7 and that helps wean more people off .NET 6. When .NET 8 eventually comes out and drops support for those operating systems, there's likely to be some complaint, but at least at that point you'll be upgrading to an LTS release unlike now where choosing .NET 7 would mean losing some operating system support AND jumping on to something without long-term support itself (which is like buying one problem and getting another problem for free grin)

It won't become a no brainer due to the fact that .Net 6 will have a longer support than .Net 7 due to being an LTS. Keeping the support for .Net 7 only makes sense if .Net 8 would also keep it since otherwise people would have to revert to .Net 6 to keep support.

[richlander]

My current thinking is:

• .NET 6 will be supported for the life of Windows 7 ESU.
• .NET 7 will not be supported on Windows 7, will not be tested, but nothing will be done to hinder it.
• Revisit with .NET 8.

[MichalPetryka]

Will it be the same with Windows 8.1 or will .Net 7 support it due to being released within its support timeframe?

[vcsjones]

NET 7 will not be supported on Windows 7, will not be tested, but nothing will be done to hinder it.

"will not be tested" does that specifically mean no CI for Windows 7?