Bump MessagePack to 2.5.302#1459
Merged
Merged
Conversation
d611796 to
d0ae95d
Compare
|
Great, I was wondering whether could bump it up! |
There was a problem hiding this comment.
Pull request overview
Updates the centrally managed MessagePack dependency version used across the solution to the newer 2.5.302 release.
Changes:
- Bump
MessagePackVersionfrom2.5.198to2.5.302in central package management. - This implicitly updates both
MessagePackandMessagePackAnalyzervia the shared version property.
olegtk
approved these changes
Jun 12, 2026
mitchdenny
added a commit
to microsoft/aspire
that referenced
this pull request
Jun 14, 2026
StreamJsonRpc 2.25.28 brings MessagePack 2.5.302 transitively, which is above the GHSA-hv8m-jj95-wg3x / CVE-2026-48109 vulnerable range. This lets us drop the direct MessagePack PackageReference (and PackageVersion) we added earlier as a workaround. StreamJsonRpc 2.25.x ships an analyzer built against Roslyn 4.14, which is newer than the Roslyn 4.11 in the .NET 8 SDK used by template tests to build generated AppHost projects (would trigger CSC error CS9057). We don't use the StreamJsonRpc analyzers anywhere in this assembly, so ExcludeAssets="analyzers" skips them. NuGet bakes the exclusion into the Aspire.Hosting nuspec so downstream consumers (AppHost projects) also skip the analyzer transitively. See microsoft/vs-streamjsonrpc#1459 for the upstream MessagePack bump. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
mitchdenny
added a commit
to microsoft/aspire
that referenced
this pull request
Jun 16, 2026
* Bump StreamJsonRpc to 2.25.25 to clear MessagePack NU1903 The aspire-starter template was emitting NU1903 for transitive MessagePack 2.5.192 (GHSA-hv8m-jj95-wg3x / CVE-2026-48109) because the shared StreamJsonRpc 2.22.23 dependency pulled it in. Updating StreamJsonRpc to 2.25.25 brings MessagePack 2.5.198, outside the advisory's vulnerable range. The advisory affects only MessagePack's LZ4 decompression path. We do not use MessagePackFormatter anywhere - all StreamJsonRpc sites use SystemTextJsonFormatter - and our JSON-RPC transports are local UDS under the user's home directory, so the underlying vulnerability was not reachable. This change is warning hygiene. Fixes #18153 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Pin MessagePack to 2.5.302 to fully clear GHSA-hv8m-jj95-wg3x StreamJsonRpc 2.25.25 still declares a transitive dep on MessagePack 2.5.198, which is inside the advisory's vulnerable range (< 2.5.302). Add a direct PackageReference on MessagePack to Aspire.Hosting so consumers (including generated AppHosts from 'aspire new aspire-starter') restore the patched version, and NU1903 is no longer emitted. This can be removed once StreamJsonRpc ships a release that depends on MessagePack >= 2.5.302. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Revert StreamJsonRpc bump; keep MessagePack 2.5.302 pin StreamJsonRpc 2.25.25 ships analyzers built against Roslyn 4.14, which breaks template tests that build generated AppHosts with the .NET 8 SDK (CSC error CS9057). The MessagePack 2.5.302 direct pin in Aspire.Hosting already overrides StreamJsonRpc 2.22.23's transitive MessagePack 2.5.192 in consumer projects, so the GHSA-hv8m-jj95-wg3x warning is silenced without needing the StreamJsonRpc bump. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Bump StreamJsonRpc to 2.25.28 and drop MessagePack pin StreamJsonRpc 2.25.28 brings MessagePack 2.5.302 transitively, which is above the GHSA-hv8m-jj95-wg3x / CVE-2026-48109 vulnerable range. This lets us drop the direct MessagePack PackageReference (and PackageVersion) we added earlier as a workaround. StreamJsonRpc 2.25.x ships an analyzer built against Roslyn 4.14, which is newer than the Roslyn 4.11 in the .NET 8 SDK used by template tests to build generated AppHost projects (would trigger CSC error CS9057). We don't use the StreamJsonRpc analyzers anywhere in this assembly, so ExcludeAssets="analyzers" skips them. NuGet bakes the exclusion into the Aspire.Hosting nuspec so downstream consumers (AppHost projects) also skip the analyzer transitively. See microsoft/vs-streamjsonrpc#1459 for the upstream MessagePack bump. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Strip StreamJsonRpc analyzer from consumer AppHost builds ExcludeAssets in Aspire.Hosting alone is not enough: the .NET 8 SDK discovers analyzer DLLs in the NuGet cache by convention regardless of the project.assets.json exclude flags, and StreamJsonRpc.Analyzers.dll (Roslyn 4.14) fails to load under SDK 8's Roslyn 4.11 with CS9057. Add a target in Aspire.Hosting.AppHost.targets that runs before CoreCompile and removes any Analyzer item whose path contains 'StreamJsonRpc.Analyzers'. Aspire doesn't depend on any of the StreamJsonRpc analyzer diagnostics, so dropping them is safe. Verified locally: building a net8.0 AppHost with the .NET 8 SDK (Roslyn 4.11) no longer hits CS9057. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Move StreamJsonRpc analyzer strip to Aspire.Hosting buildTransitive The Aspire.Hosting.AppHost targets file only reaches direct AppHost consumers — but Aspire.Hosting.Testing also pulls StreamJsonRpc in transitively, and the test project (.aspire_xunitTests.csproj) hit the same CS9057 under .NET 8 SDK. Move the analyzer-strip target into Aspire.Hosting's buildTransitive/Aspire.Hosting.targets so every consumer of Aspire.Hosting (AppHost projects, test projects, etc.) automatically drops the StreamJsonRpc analyzer. Verified locally: a net8.0 test project that references Aspire.Hosting.Testing builds cleanly under the .NET 8 SDK. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Simplify StreamJsonRpc analyzer-strip condition using %(Filename) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Bump StreamJsonRpc to 2.25.29; drop analyzer-strip workaround StreamJsonRpc 2.25.29 ships analyzers compiled against an older Roslyn that is compatible with the .NET 8 SDK (vs-streamjsonrpc#1463 / #1399), so the buildTransitive analyzer-strip target and the ExcludeAssets flag on the PackageReference are no longer needed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Revert "Bump StreamJsonRpc to 2.25.29; drop analyzer-strip workaround" This reverts commit b179c30. * Reapply "Bump StreamJsonRpc to 2.25.29; drop analyzer-strip workaround" This reverts commit 1f175af. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
joperezr
pushed a commit
to microsoft/aspire
that referenced
this pull request
Jun 16, 2026
…903 (#18204) * Bump StreamJsonRpc to 2.25.25 to clear MessagePack NU1903 The aspire-starter template was emitting NU1903 for transitive MessagePack 2.5.192 (GHSA-hv8m-jj95-wg3x / CVE-2026-48109) because the shared StreamJsonRpc 2.22.23 dependency pulled it in. Updating StreamJsonRpc to 2.25.25 brings MessagePack 2.5.198, outside the advisory's vulnerable range. The advisory affects only MessagePack's LZ4 decompression path. We do not use MessagePackFormatter anywhere - all StreamJsonRpc sites use SystemTextJsonFormatter - and our JSON-RPC transports are local UDS under the user's home directory, so the underlying vulnerability was not reachable. This change is warning hygiene. Fixes #18153 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Pin MessagePack to 2.5.302 to fully clear GHSA-hv8m-jj95-wg3x StreamJsonRpc 2.25.25 still declares a transitive dep on MessagePack 2.5.198, which is inside the advisory's vulnerable range (< 2.5.302). Add a direct PackageReference on MessagePack to Aspire.Hosting so consumers (including generated AppHosts from 'aspire new aspire-starter') restore the patched version, and NU1903 is no longer emitted. This can be removed once StreamJsonRpc ships a release that depends on MessagePack >= 2.5.302. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Revert StreamJsonRpc bump; keep MessagePack 2.5.302 pin StreamJsonRpc 2.25.25 ships analyzers built against Roslyn 4.14, which breaks template tests that build generated AppHosts with the .NET 8 SDK (CSC error CS9057). The MessagePack 2.5.302 direct pin in Aspire.Hosting already overrides StreamJsonRpc 2.22.23's transitive MessagePack 2.5.192 in consumer projects, so the GHSA-hv8m-jj95-wg3x warning is silenced without needing the StreamJsonRpc bump. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Bump StreamJsonRpc to 2.25.28 and drop MessagePack pin StreamJsonRpc 2.25.28 brings MessagePack 2.5.302 transitively, which is above the GHSA-hv8m-jj95-wg3x / CVE-2026-48109 vulnerable range. This lets us drop the direct MessagePack PackageReference (and PackageVersion) we added earlier as a workaround. StreamJsonRpc 2.25.x ships an analyzer built against Roslyn 4.14, which is newer than the Roslyn 4.11 in the .NET 8 SDK used by template tests to build generated AppHost projects (would trigger CSC error CS9057). We don't use the StreamJsonRpc analyzers anywhere in this assembly, so ExcludeAssets="analyzers" skips them. NuGet bakes the exclusion into the Aspire.Hosting nuspec so downstream consumers (AppHost projects) also skip the analyzer transitively. See microsoft/vs-streamjsonrpc#1459 for the upstream MessagePack bump. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Strip StreamJsonRpc analyzer from consumer AppHost builds ExcludeAssets in Aspire.Hosting alone is not enough: the .NET 8 SDK discovers analyzer DLLs in the NuGet cache by convention regardless of the project.assets.json exclude flags, and StreamJsonRpc.Analyzers.dll (Roslyn 4.14) fails to load under SDK 8's Roslyn 4.11 with CS9057. Add a target in Aspire.Hosting.AppHost.targets that runs before CoreCompile and removes any Analyzer item whose path contains 'StreamJsonRpc.Analyzers'. Aspire doesn't depend on any of the StreamJsonRpc analyzer diagnostics, so dropping them is safe. Verified locally: building a net8.0 AppHost with the .NET 8 SDK (Roslyn 4.11) no longer hits CS9057. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Move StreamJsonRpc analyzer strip to Aspire.Hosting buildTransitive The Aspire.Hosting.AppHost targets file only reaches direct AppHost consumers — but Aspire.Hosting.Testing also pulls StreamJsonRpc in transitively, and the test project (.aspire_xunitTests.csproj) hit the same CS9057 under .NET 8 SDK. Move the analyzer-strip target into Aspire.Hosting's buildTransitive/Aspire.Hosting.targets so every consumer of Aspire.Hosting (AppHost projects, test projects, etc.) automatically drops the StreamJsonRpc analyzer. Verified locally: a net8.0 test project that references Aspire.Hosting.Testing builds cleanly under the .NET 8 SDK. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Simplify StreamJsonRpc analyzer-strip condition using %(Filename) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Bump StreamJsonRpc to 2.25.29; drop analyzer-strip workaround StreamJsonRpc 2.25.29 ships analyzers compiled against an older Roslyn that is compatible with the .NET 8 SDK (vs-streamjsonrpc#1463 / #1399), so the buildTransitive analyzer-strip target and the ExcludeAssets flag on the PackageReference are no longer needed. Mirrors the final state of #18155 on main. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Mitch Denny <midenn@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.