Skip to content

[automated] Merge branch 'release/9.0' => 'release/9.0-staging'#124245

Merged
steveisok merged 15 commits intorelease/9.0-stagingfrom
merge/release/9.0-to-release/9.0-staging
Mar 2, 2026
Merged

[automated] Merge branch 'release/9.0' => 'release/9.0-staging'#124245
steveisok merged 15 commits intorelease/9.0-stagingfrom
merge/release/9.0-to-release/9.0-staging

Conversation

@github-actions
Copy link
Contributor

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:

  • wfurt
  • vseanreesermsft
  • bartonjs

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.

merge button instructions

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.

git fetch
git checkout release/9.0
git pull --ff-only
git checkout release/9.0-staging
git pull --ff-only
git merge --no-ff release/9.0

# If there are merge conflicts, resolve them and then run git merge --continue to complete the merge
# Pushing the changes to the PR branch will re-trigger PR validation.
git push https://github.com/dotnet/runtime HEAD:merge/release/9.0-to-release/9.0-staging
or if you are using SSH
git push git@github.com:dotnet/runtime HEAD:merge/release/9.0-to-release/9.0-staging

After PR checks are complete push the branch

git push

Instructions for resolving conflicts

⚠️ If there are merge conflicts, you will need to resolve them manually before merging. You can do this using GitHub or using the command line.

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.

git fetch
git checkout -b merge/release/9.0-to-release/9.0-staging origin/release/9.0-staging
git pull https://github.com/dotnet/runtime merge/release/9.0-to-release/9.0-staging
(make changes)
git commit -m "Updated PR with my changes"
git push https://github.com/dotnet/runtime HEAD:merge/release/9.0-to-release/9.0-staging
or if you are using SSH
git fetch
git checkout -b merge/release/9.0-to-release/9.0-staging origin/release/9.0-staging
git pull git@github.com:dotnet/runtime merge/release/9.0-to-release/9.0-staging
(make changes)
git commit -m "Updated PR with my changes"
git push git@github.com:dotnet/runtime HEAD:merge/release/9.0-to-release/9.0-staging

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.

dotnet-maestro bot and others added 5 commits February 11, 2026 16:27
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>
…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 steveisok added the Servicing-approved Approved for servicing release label Mar 2, 2026
@steveisok steveisok self-requested a review March 2, 2026 13:54
@steveisok steveisok enabled auto-merge (squash) March 2, 2026 13:54
@steveisok steveisok merged commit 0299cc3 into release/9.0-staging Mar 2, 2026
146 of 154 checks passed
@steveisok steveisok deleted the merge/release/9.0-to-release/9.0-staging branch March 2, 2026 21:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-codeflow for labeling automated codeflow Servicing-approved Approved for servicing release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants