-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WinHttpHandler: apply [SupportedOSPlatform("windows10.0.19041")] on TcpKeepAlive properties #45494
WinHttpHandler: apply [SupportedOSPlatform("windows10.0.19041")] on TcpKeepAlive properties #45494
Conversation
Tagging subscribers to this area: @dotnet/ncl Issue Details
As discussed, I'm applying the internal variant of This change finishes and resolves #44025.
|
@@ -44,8 +44,11 @@ public partial class WinHttpHandler : System.Net.Http.HttpMessageHandler | |||
public System.Func<System.Net.Http.HttpRequestMessage, System.Security.Cryptography.X509Certificates.X509Certificate2, System.Security.Cryptography.X509Certificates.X509Chain, System.Net.Security.SslPolicyErrors, bool>? ServerCertificateValidationCallback { get { throw null; } set { } } | |||
public System.Net.ICredentials? ServerCredentials { get { throw null; } set { } } | |||
public System.Security.Authentication.SslProtocols SslProtocols { get { throw null; } set { } } | |||
[System.Runtime.Versioning.SupportedOSPlatformAttribute("windows10.0.2004")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should not it be 10.0.19041 (ie. the real version number, not the marketing one)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK the $"{year:00}{month:00}"
thing is the Version, 19041
is the Build. See also the windows samples for SupportedOSPlatform
: https://github.com/dotnet/designs/blob/main/accepted/2020/platform-exclusion/platform-exclusion.md#attribute
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds confusing as hell since the TFMs use the build numbers (https://blogs.windows.com/windowsdeveloper/2020/11/10/announcing-c-winrt-version-1-0-with-the-net-5-ga-release/).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like a valid concern, although nothing we can do at this point I guess. @terrajobst any comments on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The official documentation also uses the build numbers (https://docs.microsoft.com/en-us/dotnet/standard/analyzers/platform-compat-analyzer)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I'm pretty sure now we should use Build here, and there is a bug in the design doc. Opened dotnet/designs#170 to get it clarified. Thanks a lot for spotting this!
Tagging subscribers to this area: @dotnet/ncl Issue Details
As discussed, I'm applying the internal variant of This change finishes and resolves #44025.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Didn't we plan to define a SupportedOSPlatform attribute inside this, as we don't have a .NET 5 build? |
That should be happening automatically: runtime/src/libraries/Directory.Build.targets Lines 242 to 249 in ed29578
|
/azp run runtime-libraries-coreclr outerloop |
Azure Pipelines successfully started running 1 pipeline(s). |
According to the feedback around #45494 (comment), the change of |
WINHTTP_OPTION_TCP_KEEPALIVE
is only available since the May 2020 Update, so it's reasonable to mark the corresponding managed API-s with[SupportedOSPlatform("windows10.0.2004")]
.As discussed, I'm applying the internal variant of
SupportedOSPlatformAttribute
in all build targets for simplicity. Note that with this solution the attribute does not contribute to the public API as it was originally suggested in the proposal #44025.This change finishes and resolves #44025.
/cc @scalablecory @ericstj