Core: Update OS support page to better clarify Win7 ESU support

[eriawan]

Could we drop Windows 7 support in .NET 5.0?

We need to consider to drop Windows 7 support, because Windows 7 SP1 has reached end of extended support timeline.

General background

I've read carefully this SDK doc of supported platform:
https://github.com/dotnet/core/blob/master/release-notes/5.0/5.0-supported-os.md

It mentions about supporting Windows 7. But according to official Windows client lifecycle page, Windows 7 SP1 extended support ends on January 2020:

link: https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet
and this is the link on the date link:
https://support.microsoft.com/en-us/help/4057281/windows-7-support-ended-on-january-14-2020

CMIIW, but looking at the TFM list support of NET 5.0, there's also support for Windows 7 as one of the TFM, and this Windows 7 support is also permeated (as usages or references) in dotnet/runtime, dotnet/winforms, dotnet/wpf repo as well.

Additional Rationale

Not just having the fact of ending support of Windows 7 SP1, but we may face this risk:

1. .NET 5 and the previous releases such as .NET Core 3.1 and 3.0 always has the "policy" of supporting OS according to its lifecycle (see image below). Having support of Windows 7 in .NET 5 seems breaking this policy.
2. It is also not making sense to have .NET 5 released with Windows 7 support when Windows 7 is not supported anymore before .NET 5 is released. When I discuss this with my fellow dev team, we feel that what's the compelling point/reasoning here to support running .NET on not supported OS?
3. In the perspective of .NET 5 deployment in ops, we have the perspective of "it's ok to use .NET 5 in Windows 7 although Windows 7 is not supported anymore", therefore it seems it's inviting misunderstanding for the ops team. My fellow ops team members are asking this too, and it's not completely against their policy to avoid unsupported OS, but they still have to face questions from other dept in our dev dept that they may not be able to answer in correct manner, such as if there's question about other department would be ok to not upgrading their Windows 7 machine, because the upcoming NET 5 will support it.

This is the policy I meant in point 1:

PS: I apologize if my English is incorrect, or if I may sound harsh. I hope we should have paid more attention to OS lifecycle and avoid inconsistent or breaking of current OS lifecycle alignment.

[GrabYourPitchforks]

/cc @leecow @richlander

[yoshiask]

Considering that .NET 5 is being touted as the future of .NET as a whole, it doesn't really make sense to support an OS that is not just legacy at this point, but is also well out of support (even after a support period much longer than usual).

[eriawan]

Additional note:

If my suggestion is accepted, should we consider this issue as critical showstopper? because I'm aware if this suggestion is accepted, we may have to have large changes on the whole existing infrastructure of SDK, Corelib, runtime, BCLs, and also those repos that has explicit Windows specific, such as Winforms and WPF.

Hopefully I'm not dragging or interrupting the whole planned schedule of .NET 5 release....

[john-h-k]

I can't see why removing OS support would require large changes. It might enable large changes that would previously break compat, but why would it require changes?

[eriawan]

@john-h-k
IMHO it requires quite careful changes because it may break not just the existing SDK, but also others.

Yes, I might be wrong on "large changes", but I personally have looked at how the TFMs and the related RIDs are used in the SDK, coreclr, runtime, and on the windows specific repos such as WinForms and WPF,
As far as I know, there are also numerous checks on the Windows specific features that has Windows version-specific logics.

I know that we could assume about this fact: on normal .NET Core class library, console, unit tests projects that has no Windows specific API dependencies, I think we could safely assume these project types aren't affected by removing Windows 7 support.

Maybe @richlander or the rest of dotnet core team can give feedback too?

[199621616]

强烈反对！
思考问题，应当从实际出发，而不应当从本本出发、从个人愿望出发。要知道，目前全世界使用Windows的用户中使用Windows7的仍然高达50%甚至更多。删除对Windows7的支持，意味着把高达50%的Windows用户拒之门外。如果微软到今天仍然没有从原来的状态走出来，那么所有的ISV、所有的用户，可能就要彻底的抛弃微软。从而，会把微软带入万劫不复的境地。
但是，我不反对以后的版本停止支持Windows7。比如，从NET 7开始。让用户有进入NET的机会。
Strongly against it!
To think about problems, we should proceed from the reality, not from the book and personal wishes. It should be noted that at present, 50% or even more users of windows use Windows 7 all over the world. Removing support for Windows 7 means shutting out up to 50% of Windows users. If Microsoft still does not come out of its original state, then all ISVs and all users may have to abandon Microsoft completely. As a result, it will bring Microsoft into an irreparable situation.
However, I have no objection to discontinuing support for Windows 7 in future versions. For example, start with net 7. Let users have access to net.

[eriawan]

@199621616
Pardon, you are discussing something different. Support of Windows 7 and Windows 7 SP1 support are already ended.
My main focus is the .NET 5.0 support for Windows 7 should be reconsidered again, because Windows 7 is not supported anymore.

[eriawan]

This issue has been about 4 days without any reply/confirmation...

Please review at least confirm. guys..

cc @richlander @leecow

[199621616]

@eriawan 伊里亚 NET 5.0删除对Windows 7的支持，等于把许多微软传统的用户拒之门外。最近这些年，越来越多的ISV逃离微软。现在刚刚因为.NetCore有点转机，怎么又来这类想法？Windows Phone失败了、Silverlight抛弃了、Windows Runtime不死不活，难道想让NET 5.0也步其后尘，把最基本盘中最大的一块支持力量割掉它？再失去它，还有谁用NET 5.0 ?难道微软开发NET 5.0不是为了使用嘛？把最基本的力量都赶跑了，你自己用它？

@The removal of Windows 7 support by eriawan Iria net 5.0 is tantamount to the exclusion of many traditional Microsoft users. In recent years, more and more ISVs have fled Microsoft. Now, NETCORE has a new idea? Windows Phone failed, Silverlight was abandoned, and windows runtime was dead. Do you want net 5.0 to follow suit and cut off the largest piece in the most basic disk? If you lose it, who else will use net 5.0? Isn't Microsoft developing net 5.0 to use it? Get rid of the most basic power, use it yourself?

[richlander]

The Windows team has a program called Extended Security Updates for Windows 7 (ESU). We expect that many of the companies that purchase this offering will run .NET applications on their Windows 7 PCs. The offering will be significantly more attractive and coherent if .NET support is included (.NET Framework, .NET Core). As a result, we decided to continue supporting Windows 7 for .NET 5.0. This also means that .NET Core 2.1 and 3.1 remain supported on Windows 7. We'll re-assess this need for .NET 6.0. To avoid leaving people wondering, our bias will be to support the ESU program while it is made available.

Product behavior:

• .NET Framework security updates will check for a valid ESU license, upon installation.
• .NET Core and .NET 5 installers will not check for a valid ESU license (at any point).

When we do remove support for Windows 7, we don't expect major architectural changes. I have been told that there is a significant amount of Windows 7 specific code that will be removed at the point that we drop support for Windows 7.

I appreciate the enthusiasm to get an answer on this topic. Most of the past four days were a holiday for us, observing the American Independence day.

[GrabYourPitchforks]

The .NET products will not check that an ESU license has been purchased.

A quick clarification on this point.

__.NET Framework__ (2.0, 3.5, 4.5+) installers, including installers for security patches, may check that the target Windows 7 machine has a valid ESU license. The security patch installers may refuse to run if they cannot find a valid ESU license.

__.NET Core__ (2.1.x, 3.1.x) and __.NET 5.0+__ installers do not check for the ESU license.

[richlander]

Thanks. I updated my comment to include that info.

[eriawan]

@richlander

Many thanks for your reply! I'm so glad and relieved that I finally got some answers 🙂
I apologize that all of you in US has independence holiday, I thought it was from 3rd to 4th July.

About this:

The Windows team has a program called Extended Security Updates for Windows 7 (ESU). We expect that many of the companies that purchase this offering will run .NET applications on their Windows 7 PCs. The offering will be significantly more attractive and coherent if .NET support is included (.NET Framework, .NET Core). As a result, we decided to continue supporting Windows 7 for .NET 5.0.

and this:

We'll re-assess this need for .NET 6.0. To avoid leaving people wondering, our bias will be to support the ESU program while it is made available.

I still have some additional questions:

1. The Windows 7 ESU is for those customers that are purchasing additional support, this means it's not generally available for everyone that has Windows 7 SP1, as you also stated it's usually purchased by companies. I assume that this Windows 7 ESU support is still quite contrary against the article about "supported OS policy of .NET Core": https://github.com/dotnet/core/blob/master/os-lifecycle-policy.md , therefore can we update this page with additional clarification on Windows 7 ESU special case support?
2. Adding Windows 7 ESU means that this ESU will extend the Windows 7 paid support for 3 years after January 14, 2020. CMIIW, this means Windows 7 with ESU will be valid until about January 2023. Do we really have to ensure support for Windows 7 in .NET 6.0 and .NET 7.0 as well? It is a little bit contradictory for me that if .NET 5.0 still support Windows 7 due to ESU, then does this mean that even until .NET 7.0 we have to provide support for Windows 7? The main reason I asked this because I assume that NET 7.0 has to support Windows 7 because .NET 7.0 will be RTM'ed in 2022, and it's still within the period of Windows 7 ESU.
3. If .NET 5.0 support Windows 7 because of the Windows 7 ESU, is this policy also applicable to Windows 8.1 if Windows 8.1 has ESU support?
4. Based on question no. 3 above, will the ESU availability will be the base of the minimum Windows support for .NET 5.0 and later?

Apologize, the reason of question no. 4 is because it will be easier to have a consistent reasoning for ESU related reason for minimum base Windows version, especially if this ESU reasoning is documented in the current OS lifecycle policy page

Thanks for confirming about the possibility of quite large changes in the .NET Core codebase if we remove Windows 7 support.

[richlander]

We're getting into a level of detail that doesn't matter to most people. There are three key points that answer most of your questions:

• We will only test on Windows 7 with the ESU updates installed. If we did otherwise, our test infrastructure would not be secure.
• I am assuming that Microsoft Support will require that customers have purchased an ESU license in order to provide support for Windows 7.
• We will make our support plans for Windows 7 ESU on a release-by-release basis, as I suggested in my initial comment.

It would be helpful to link to the ESU page from our support pages. We'll do that.

[Raviuppa]

For WPF and Winforms, we do see issues that are related to underneath Windows. If we support .NET 5 on Win7 SP1 and the issue is due to Windows components and not any related to .NET 5 for WPF/Winforms, can we provide a Windows fix for that unsupported OS? No, right? ESU covers only security features and it doesn't help for any regular Windows bugs. Hence, I would suggest to drop Win7 SP1 support for .NET 5.

[richlander]

You are correct. We will not be able to provide a solution for Windows-specific issues in Windows 7. We will be able to make fixes to .NET itself. I suspect that most Windows 7 ESU users would be happy with that tradeoff. We should also recognize that our ability to get functionality fixes into supported versions Windows, like Windows 10 RS1, for example, isn't significantly better.

[GrabYourPitchforks]

Marking a reported bug "won't fix" is also a viable option. It really depends on the severity of the issue, the number of impacted customers, and the cost / benefit analysis of making the change.

[Raviuppa]

No matter how severe the issue is, I do not think there is any such critical non security fixes provision for Win7 SP1 which is already reached EOL. Rather going through multiple hoops and eventually to end up as "Won't Fix", dropping the EOL OSs as supported OS for .NET 5 would be ideal.

[GrabYourPitchforks]

Rather going through multiple hoops and eventually to end up as "Won't Fix"

Do you think it's likely there will be multiple hoops? I'm hoping it would be straightforward: user reports bug, repros only in Win7 SP1, not a regression from Full Framework, advise to use whatever workaround existing Full Framework customers are using, close "won't fix."

[Raviuppa]

From Support point of view, having an unsupported option on the Sys Req page is ideal than having customers to reach out to support to get the answer. Its not just about issues surface on GitHub but also issues reported to Microsoft Support.

[eriawan]

@Raviuppa

From Support point of view, having an unsupported option on the Sys Req page is ideal than having customers to reach out to support to get the answer. Its not just about issues surface on GitHub but also issues reported to Microsoft Support.

I agree. Not to mention it would be hard to justify EOL OS such as Windows 7 SP1 to be supported when there would be possible issues that is related to Windows 7 SP1 that might be related to non-security related issues. For example: Windows 7 still has bugs on WPF-specific issues, and there might be mixed problems on how to ask for support.

i.e. there should be clear explicit boundary about which issue related to .NET 5.0 support, and which issues should be treated as Not Fixed or redirected to Windows support team.

Then the OS update policy page and the OS requirements of .NET 5.0 OS should also explicitly mention these clarifications as well.

Based on the discussions above, I personally think having not supporting EOL OS such as Windows 7 SP1 brings less confusion and less support problems, especially if we know that the Windows 7 ESU only has security updates, not the WPF/Winforms related updates.
At the same time, removing support for Windows 7 also brings strong justifications for most Ops departments, as they won't have to support EOL OS, Most enterprise will weigh in more on supported OS instead of keeping up supporting Windows 7 with higher cost of obtaining Windows 7 ESU (in terms/perspective of Total Cost of Ownership) .

Therefore the advantages are more making sense in terms of maintenance and also easier to move forward, IMHO.
And maybe less maintenance on .NET 5.0, as removed Windows 7 means lesser RID to maintain and to support 🙂

Anyway, thanks for this healthy discussions and the confirmations from .NET team! 👍

[GrabYourPitchforks]

@richlander I assume when you said "update the support pages" you meant update https://github.com/dotnet/core/blob/master/release-notes/5.0/5.0-supported-os.md? Assigning this issue to you to track putting the blurb there.

[jamshedd]

From Support point of view, having an unsupported option on the Sys Req page is ideal than having customers to reach out to support to get the answer. Its not just about issues surface on GitHub but also issues reported to Microsoft Support.

I appreciate the simplicity of such a message, but that might also be throwing out the baby with the bathwater. I would argue that the vast majority of enterprise customers that use .NET 5 on Win7 SP1 (with an ESU contract) would be able to do so successfully and even get .NET support without ever having to request an OS hotfix for a boundary case. This suggests the majority of customers will benefit from this support rather than encounter the confusing won't fix situation. Alternatively, if there is data showing a preponderance of these boundary cases where an OS fix is required to address an issue in .NET then I would be interested in that.

[GrabYourPitchforks]

I updated the issue title to better reflect the requested work as stated in https://github.com/dotnet/core/issues/4894#issuecomment-654447741.

[eriawan]

hi @GrabYourPitchforks @richlander

Is there any update/progress related to clarification of Windows 7 ESU on this https://github.com/dotnet/core/blob/master/release-notes/5.0/5.0-supported-os.md page?

Last update of 7 days ago, and it doesn't mention any clarification about Windows 7 ESU against normal or commonly used OS lifecycle support.

[xtqqczze]

It would also be good to clarify support for Windows Server 2012, which does not reach end-of-life until 2023-10-10 and is currently excluded for support in .NET 5.0, see #4668.

[jamshedd]

@xtqqczze there is no plan to change our support position on Windows Server 2012. A newer version in the same server family is available in the form of Server 2012 R2, the expectation is that the newer R2 version is used in order to be in a supported state. While both Server 2012 and Windows 7 are still in use the decisions for the two platforms were made independently given the usage of the two platforms in the ecosystem is quite different.

I do realize that there is a conflict between the general statement around supporting OS platforms while they're still in support and specific instances like the Server 2012 case and Windows 7 SP1 ESU program and this conflict can cause confusion. I think we can adequately address that by adding a statement on our main lifecycle page for this - when there's a conflict between the general policy statement and the support platforms listed for a specific version of .NET, the latter will prevail.

[icnocop]

@xtqqczze there is no plan to change our support position on Windows Server 2012. A newer version in the same server family is available in the form of Server 2012 R2, the expectation is that the newer R2 version is used in order to be in a supported state. ... I think we can adequately address that by adding a statement on our main lifecycle page for this - when there's a conflict between the general policy statement and the support platforms listed for a specific version of .NET, the latter will prevail.

Should this page be updated then?
https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2012

Thank you.

[jamshedd]

@xtqqczze there is no plan to change our support position on Windows Server 2012. A newer version in the same server family is available in the form of Server 2012 R2, the expectation is that the newer R2 version is used in order to be in a supported state. ... I think we can adequately address that by adding a statement on our main lifecycle page for this - when there's a conflict between the general policy statement and the support platforms listed for a specific version of .NET, the latter will prevail.

Should this page be updated then?
https://docs.microsoft.com/en-us/lifecycle/products/windows-server-2012

Thank you.

Not quite. We can only update .NET Core lifecycle policy, not the OS itself. We have made the planned updates here (see the section on exceptions towards the end):

https://github.com/dotnet/core/blob/master/os-lifecycle-policy.md