[automated] Merge branch 'release/9.0' => 'release/9.0-staging'#124245
Merged
steveisok merged 15 commits intorelease/9.0-stagingfrom Mar 2, 2026
Merged
[automated] Merge branch 'release/9.0' => 'release/9.0-staging'#124245steveisok merged 15 commits intorelease/9.0-stagingfrom
steveisok merged 15 commits intorelease/9.0-stagingfrom
Conversation
CoseMessage's Decode routines say that any failure is a CryptographicException, but some of the validation failures leak out ArgumentException from the validation in CoseHeaderMap.
…-merge-9.0-2026-02-10-1047
This pull request updates the following dependencies [marker]: <> (Begin:f85f62c8-5e7d-4706-1003-08dcbc30275f) ## From https://github.com/dotnet/emsdk - **Subscription**: [f85f62c8-5e7d-4706-1003-08dcbc30275f](https://maestro.dot.net/subscriptions?search=f85f62c8-5e7d-4706-1003-08dcbc30275f) - **Build**: [20260210.3](https://dev.azure.com/dnceng/internal/_build/results?buildId=2900196) ([301162](https://maestro.dot.net/channel/3883/github:dotnet:emsdk/build/301162)) - **Date Produced**: February 10, 2026 4:20:20 PM UTC - **Commit**: [fb1326b0f4622f04f21584dc133f1c71f7554509](dotnet/emsdk@fb1326b) - **Branch**: [release/9.0](https://github.com/dotnet/emsdk/tree/release/9.0) [DependencyUpdate]: <> (Begin) - **Dependency Updates**: - From [9.0.14-servicing.26102.1 to 9.0.14-servicing.26110.3][4] - Microsoft.SourceBuild.Intermediate.emsdk - Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport - From [9.0.14 to 9.0.14][4] - Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100 [4]: dotnet/emsdk@c66fdc1...fb1326b [DependencyUpdate]: <> (End) [marker]: <> (End:f85f62c8-5e7d-4706-1003-08dcbc30275f) [marker]: <> (Begin:Coherency Updates) ## Coherency Updates The following updates ensure that dependencies with a *CoherentParentDependency* attribute were produced in a build used as input to the parent dependency's build. See [Dependency Description Format](https://github.com/dotnet/arcade/blob/master/Documentation/DependencyDescriptionFormat.md#dependency-description-overview) [DependencyUpdate]: <> (Begin) - **Coherency Updates**: - **runtime.linux-arm64.Microsoft.NETCore.Runtime.JIT.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.linux-x64.Microsoft.NETCore.Runtime.JIT.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.JIT.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.linux-musl-x64.Microsoft.NETCore.Runtime.JIT.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.win-arm64.Microsoft.NETCore.Runtime.JIT.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.win-x64.Microsoft.NETCore.Runtime.JIT.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.osx-arm64.Microsoft.NETCore.Runtime.JIT.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.osx-x64.Microsoft.NETCore.Runtime.JIT.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.linux-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.linux-musl-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.linux-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.linux-musl-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.win-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.osx-arm64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Sdk**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) - **runtime.osx-x64.Microsoft.NETCore.Runtime.Mono.LLVM.Tools**: from 19.1.0-alpha.1.26071.2 to 19.1.0-alpha.1.26104.3 (parent: Microsoft.NET.Workload.Emscripten.Current.Manifest-9.0.100.Transport) [DependencyUpdate]: <> (End) [marker]: <> (End:Coherency Updates) --------- Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com> Co-authored-by: richlander <2608468+richlander@users.noreply.github.com> Co-authored-by: Miha Zupan <mihazupan.zupan1@gmail.com> Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Sven Boemer <sbomer@gmail.com> Co-authored-by: Vladimir Sadov <vsadov@microsoft.com> Co-authored-by: Steve Pfister <steveisok@users.noreply.github.com> Co-authored-by: Alexander Köplinger <alex.koeplinger@outlook.com> Co-authored-by: Jeff Handley <jeffhandley@users.noreply.github.com> Co-authored-by: elinor-fung <47805090+elinor-fung@users.noreply.github.com> Co-authored-by: Elinor Fung <elfung@microsoft.com> Co-authored-by: Andy Gocke <angocke@microsoft.com> Co-authored-by: Eric StJohn <ericstj@microsoft.com> Co-authored-by: Matous Kozak <matouskozak@seznam.cz> Co-authored-by: Filip Navara <filip.navara@gmail.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Larry Ewing <lewing@microsoft.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Jeremy Koritzinsky <jekoritz@microsoft.com> Co-authored-by: Marie Píchová <11718369+ManickaP@users.noreply.github.com>
This reverts commit cbb9e77.
…ue for UNC paths (#124867) `ResolveLinkTarget_Succeeds` fails with `IOException: The specified network name is no longer available` on Windows versions that have UNC access disabled, because `SymbolicLink_ResolveLinkTarget_PathToTarget_Data` was yielding UNC paths with `returnFinalTarget=true`, causing Windows to actually attempt to resolve `\\LOCALHOST\share\path`. main PR <!-- Link to PR if any that fixed this in the main branch. --> # Description - In `BaseSymbolicLinks.cs`, split `SymbolicLink_ResolveLinkTarget_PathToTarget_Data` to iterate `PathToTargetData` with both `returnFinalTarget=false/true`, but restrict `PathToTargetUncData` to `returnFinalTarget=false` only - Non-UNC path behavior is unchanged; UNC paths still get basic symlink target verification without the network resolution step that fails on restricted machines ```csharp foreach (string path in PathToTargetData) { yield return new object[] { path, false }; yield return new object[] { path, true }; } // UNC paths are excluded from the returnFinalTarget=true case since // they throw "The specified network name is no longer available" in // various Windows versions. #120380 foreach (string path in PathToTargetUncData) { yield return new object[] { path, false }; } ``` # Customer Impact Tests in `FileInfo_SymbolicLinks`, `File_SymbolicLinks`, `DirectoryInfo_SymbolicLinks`, and `Directory_SymbolicLinks` are failing on affected Windows machines, blocking CI. # Regression Not a product regression — test infrastructure issue. Triggered by Windows policy changes disabling UNC paths on certain machines. # Testing Minimal test-only change. The fix narrows the test matrix for UNC paths to avoid exercising the network resolution path that is unavailable on restricted machines. # Risk Very low. Single-line logic change scoped entirely to test data generation. No production code touched. Reduces test coverage only for a scenario (`returnFinalTarget=true` on UNC paths) that cannot reliably run in affected environments. # 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. <!-- START COPILOT ORIGINAL PROMPT --> <details> <summary>Original prompt</summary> > ## Problem > > As reported in #120380, the test `ResolveLinkTarget_Succeeds` (used by `FileInfo_SymbolicLinks`, `File_SymbolicLinks`, `DirectoryInfo_SymbolicLinks`, `Directory_SymbolicLinks`) is failing on various Windows versions that have recently disabled UNC paths with: > > ``` > System.IO.IOException : The specified network name is no longer available > ``` > > The failure occurs because `SymbolicLink_ResolveLinkTarget_PathToTarget_Data` in `BaseSymbolicLinks.cs` yields UNC paths (from `PathToTargetUncData`) with `returnFinalTarget=true`. When resolving a symlink target with `returnFinalTarget=true`, Windows tries to actually resolve the UNC path `\\LOCALHOST\share\path`, which fails on machines where UNC is disabled. > > ## Fix > > In the file `src/libraries/System.Runtime/tests/System.IO.FileSystem.Tests/Base/SymbolicLinks/BaseSymbolicLinks.cs`, modify the `SymbolicLink_ResolveLinkTarget_PathToTarget_Data` property (lines 56-66) so that UNC paths only yield test cases with `returnFinalTarget=false`, not `true`. > > Current code (lines 56-66): > ```csharp > public static IEnumerable<object[]> SymbolicLink_ResolveLinkTarget_PathToTarget_Data > { > get > { > foreach (string path in PathToTargetData.Union(PathToTargetUncData)) > { > yield return new object[] { path, false }; > yield return new object[] { path, true }; > } > } > } > ``` > > The fix should change this to iterate `PathToTargetData` with both `false` and `true`, but iterate `PathToTargetUncData` with only `false`: > > ```csharp > public static IEnumerable<object[]> SymbolicLink_ResolveLinkTarget_PathToTarget_Data > { > get > { > foreach (string path in PathToTargetData) > { > yield return new object[] { path, false }; > yield return new object[] { path, true }; > } > // UNC paths are excluded from the returnFinalTarget=true case since > // they throw "The specified network name is no longer available" in > // various Windows versions. #120380 > foreach (string path in PathToTargetUncData) > { > yield return new object[] { path, false }; > } > } > } > ``` > > Only this one property needs to change. The other data properties (`SymbolicLink_LinkTarget_PathToTarget_Data`, `Junction_*`) should remain unchanged. </details> <!-- START COPILOT CODING AGENT SUFFIX --> *This pull request was created from Copilot chat.* > <!-- START COPILOT CODING AGENT TIPS --> --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: jozkee <16040868+jozkee@users.noreply.github.com>
steveisok
approved these changes
Mar 2, 2026
3 tasks
Member
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.
I detected changes in the release/9.0 branch which have not been merged yet to release/9.0-staging. I'm a robot and am configured to help you automatically keep release/9.0-staging up to date, so I've opened this PR.
This PR merges commits made on release/9.0 by the following committers:
Instructions for merging from UI
This PR will not be auto-merged. When pull request checks pass, complete this PR by creating a merge commit, not a squash or rebase commit.
If this repo does not allow creating merge commits from the GitHub UI, use command line instructions.
Instructions for merging via command line
Run these commands to merge this pull request from the command line.
or if you are using SSH
After PR checks are complete push the branch
Instructions for resolving conflicts
Instructions for updating this pull request
Contributors to this repo have permission update this pull request by pushing to the branch 'merge/release/9.0-to-release/9.0-staging'. This can be done to resolve conflicts or make other changes to this pull request before it is merged.
The provided examples assume that the remote is named 'origin'. If you have a different remote name, please replace 'origin' with the name of your remote.
or if you are using SSH
Contact .NET Core Engineering (dotnet/dnceng) if you have questions or issues.
Also, if this PR was generated incorrectly, help us fix it. See https://github.com/dotnet/arcade/blob/main/.github/workflows/scripts/inter-branch-merge.ps1.