Skip to content

[release/9.0-staging] Update MsQuic to 2.5.12 - #135884

Merged
ViveliDuCh merged 1 commit into
dotnet:release/9.0-stagingfrom
ViveliDuCh:msquic-2.5.12-release-9.0-staging
Oct 15, 2026
Merged

ViveliDuCh merged 1 commit into
dotnet:release/9.0-stagingfrom
ViveliDuCh:msquic-2.5.12-release-9.0-staging

Conversation

@ViveliDuCh

Copy link
Copy Markdown
Member

Fixes #135880

main PR #135749

Description

Updates the public release/9.0 servicing branch to use the publicly available MsQuic 2.5.12 package. This completes the private-to-public security servicing handoff so internal-to-public merges do not retain the private 2.5.11-ci.159417053 identifier that public CI cannot restore.

Customer Impact

Public release/9.0 builds fail restore with NU1603 because the private MsQuic servicing package is unavailable to public CI, blocking clean servicing builds.

Regression

This is not a product-code regression. The failure occurs during the post-disclosure dependency handoff from private MSRC bits to the corresponding public package.

Testing

Passed:

.\dotnet.cmd restore .\src\libraries\System.Net.Quic\src\System.Net.Quic.csproj /p:TargetOS=windows /p:TargetArchitecture=x64 --no-cache

The restore resolved MsQuic 2.5.12 without NU1603.

Risk

Low. This is a one-line patch-version dependency update to the public servicing package, with no managed-code changes. Full functional testing is delegated to CI.

Package authoring no longer needed in .NET 9

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older versions.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b0b9c360-7d5d-4fdc-bede-48036e9dd9b7
@azure-pipelines

Copy link
Copy Markdown
Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

@dotnet-policy-service

Copy link
Copy Markdown
Contributor

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries
See info in area-owners.md if you want to be subscribed.

@ViveliDuCh

ViveliDuCh commented Oct 15, 2026 •

Copy link
Copy Markdown
Member Author

Approved via email

@ViveliDuCh ViveliDuCh added the Servicing-approved Approved for servicing release label Oct 15, 2026
@ViveliDuCh

Copy link
Copy Markdown
Member Author

/ba-g DeadLetter + #134534

@ViveliDuCh
ViveliDuCh merged commit 3b202ff into dotnet:release/9.0-staging Oct 15, 2026
158 of 165 checks passed
@ViveliDuCh
ViveliDuCh deleted the msquic-2.5.12-release-9.0-staging branch October 15, 2026 22:50
ViveliDuCh added a commit that referenced this pull request Oct 16, 2026
…nternal-to-public builds (#135907)

#135884

The current internal-to-public merge against `release/9.0` is failing
across multiple Windows build legs because of the same warning-as-error:

src/libraries/System.Net.Quic/src/System.Net.Quic.csproj(0,0): error
NU1603: Warning As Error: System.Net.Quic depends on
Microsoft.Native.Quic.MsQuic.Schannel (>= 2.5.11-ci.159417053) but
Microsoft.Native.Quic.MsQuic.Schannel 2.5.11-ci.159417053 was not found.
Microsoft.Native.Quic.MsQuic.Schannel 2.5.11-rc was resolved instead.

`2.5.11-ci.159417053` is the private MsQuic package used internally
during coordinated MSRC servicing, so it is intentionally unavailable to
public builds. Now that the corresponding public servicing package is
available as `2.5.12`,
[#135884](https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdotnet%2Fruntime%2Fpull%2F135884&data=05%7C02%7Cvivianad%40microsoft.com%7C98d3318ead20454faf1908df2aee27ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C639276874519544099%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=JIfQXtmjD%2FWBgKaNh5ZZXLClxdNNZQM0b5Z60o2MNjM%3D&reserved=0)
updates `release/9.0-staging` to that version. A targeted
`System.Net.Quic` restore passed locally without `NU1603`. Once this
change reaches `release/9.0` and the internal-to-public merge is
refreshed, public CI should be able to restore the dependency normally.
ViveliDuCh added a commit that referenced this pull request Oct 16, 2026
Fixes #135880

main PR #135749

<!-- Give a brief summary of the issue and how the pull request is
fixing it. -->

Updates the public release/9.0 servicing branch to use the publicly
available MsQuic 2.5.12 package. This completes the private-to-public
security servicing handoff so internal-to-public merges do not retain
the private `2.5.11-ci.159417053` identifier that public CI cannot
restore.

<!-- What is the impact to customers of not taking this fix? -->

Public release/9.0 builds fail restore with NU1603 because the private
MsQuic servicing package is unavailable to public CI, blocking clean
servicing builds.

<!-- Is this fixing a problem that was introduced in the most recent
release, ie., fixing a regression? -->

This is not a product-code regression. The failure occurs during the
post-disclosure dependency handoff from private MSRC bits to the
corresponding public package.

<!-- What kind of testing has been done with the fix. -->

Passed:

```console
.\dotnet.cmd restore .\src\libraries\System.Net.Quic\src\System.Net.Quic.csproj /p:TargetOS=windows /p:TargetArchitecture=x64 --no-cache
```

The restore resolved MsQuic 2.5.12 without NU1603.

<!-- Please assess the risk of taking this fix. Provide details backing
up your assessment. -->

Low. This is a one-line patch-version dependency update to the public
servicing package, with no managed-code changes. Full functional testing
is delegated to CI.

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet
package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older
versions.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b0b9c360-7d5d-4fdc-bede-48036e9dd9b7
(cherry picked from commit 3b202ff)
ViveliDuCh added a commit that referenced this pull request Oct 16, 2026
Fixes #135880

main PR #135749

<!-- Give a brief summary of the issue and how the pull request is
fixing it. -->

Updates the public release/9.0 servicing branch to use the publicly
available MsQuic 2.5.12 package. This completes the private-to-public
security servicing handoff so internal-to-public merges do not retain
the private `2.5.11-ci.159417053` identifier that public CI cannot
restore.

<!-- What is the impact to customers of not taking this fix? -->

Public release/9.0 builds fail restore with NU1603 because the private
MsQuic servicing package is unavailable to public CI, blocking clean
servicing builds.

<!-- Is this fixing a problem that was introduced in the most recent
release, ie., fixing a regression? -->

This is not a product-code regression. The failure occurs during the
post-disclosure dependency handoff from private MSRC bits to the
corresponding public package.

<!-- What kind of testing has been done with the fix. -->

Passed:

```console
.\dotnet.cmd restore .\src\libraries\System.Net.Quic\src\System.Net.Quic.csproj /p:TargetOS=windows /p:TargetArchitecture=x64 --no-cache
```

The restore resolved MsQuic 2.5.12 without NU1603.

<!-- Please assess the risk of taking this fix. Provide details backing
up your assessment. -->

Low. This is a one-line patch-version dependency update to the public
servicing package, with no managed-code changes. Full functional testing
is delegated to CI.

IMPORTANT: Starting with .NET 9, you no longer need to edit a NuGet
package's csproj to enable building and bump the version.
Keep in mind that we still need package authoring in .NET 8 and older
versions.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b0b9c360-7d5d-4fdc-bede-48036e9dd9b7
(cherry picked from commit 3b202ff)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants