Update .NET SDK to 10.0.100-alpha.1.24609.2#59389
Conversation
Update .NET SDK to version 10.0.100-alpha.1.24609.2. --- updated-dependencies: - dependency-name: Microsoft.NET.Sdk dependency-type: direct:production update-type: version-update:semver-patch ... Signed-off-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
ghost
added
the
area-infrastructure
![dotnet-policy-service[bot]](https://avatars.githubusercontent.com/in/285228?s=60&v=4){kind=small}
|
These failures seem related to #58721. Looking into it. |
|
New build errors: @adityamandaleeka, could someone from your team decide how to handle this? |
JamesNK
requested review from
BrennanConroy,
JamesNK,
halter73 and
mgravell
as code owners
|
Issue for the networking team to look into this more and double check the changes made here to unstuck the build are good: |
| public SslProtocols Protocol { get; private set; } | ||
| public TlsCipherSuite? NegotiatedCipherSuite { get; private set; } | ||
| public string SniHostName { get; private set; } = default!; | ||
| [Obsolete("Obsolete on SslStream.")] |
There was a problem hiding this comment.
Do we want to use the same DiagId on these obsoletions as the ones used on SslStream? That way we (and users) don't need to suppress both 618 and SYSLIB0058.
There was a problem hiding this comment.
We don't use DiagId with obsolete attributes in ASP.NET Core: https://github.com/search?q=repo%3Adotnet%2Faspnetcore+%22%5BObsolete%22&type=code&p=1
I don't think so.
There was a problem hiding this comment.
Has there ever been a case where we need to Obsolete our API because of an underlying Obsoletion in the runtime libraries?
It feels like this is just an extension of obsoleting the underlying SslStream enums, so it feels like we should use the same DiagId.
cc'ing some devs who might have opinions - @terrajobst @bartonjs @rzikm @wfurt @halter73
There was a problem hiding this comment.
I agree with @eerhardt. There are two options to deal with obsoletions in underlying APIs:
- Suppression. If the obsoletion is in the implementation and we intend to shield the consumer by eventually moving off of the obsolete API, then suppression on our end is fine.
- Mark as obsolete. If the obsoletion is part of the API or conceptually tied to its semantics, then we should obsolete the higher level API.
For (2) it makes little sense to me to use a different diagnostic ID, because they are logically tied to the same obsoletion. If a customer suppresses one, I think they have reasonable expectation to suppress the other.
And generally speaking I believe we should virtually never obsolete without a diagnostic ID. The standard diagnostic for obsoletion applies way too broadly so we generally want to avoid cases where customers feel like should suppress all obsoletions.
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
wfurt
left a comment
wfurt
left a comment
There was a problem hiding this comment.
The SslStream change looks good to me.
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com> Co-authored-by: Mackinnon Buck <[email protected]> Co-authored-by: James Newton-King <[email protected]>
6 participants
Updates the .NET SDK to version
10.0.100-alpha.1.24609.2, which includes version10.0.0-alpha.1.24570.9of the .NET runtime.This pull request was auto-generated by GitHub Actions.