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.
|
| 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.
Should not it be 10.0.19041 (ie. the real version number, not the marketing one)?
There was a problem hiding this comment.
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.
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.
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.
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.
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.
|
|
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 |
antonfirsov
changed the title
|
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
According to the feedback around #45494 (comment), the change of |
ghost
locked as resolved and limited conversation to collaborators
7 participants
WINHTTP_OPTION_TCP_KEEPALIVEis 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
SupportedOSPlatformAttributein 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