[main] Update dependencies from dotnet/dotnet

[dotnet-maestro]

This pull request updates the following dependencies

From https://github.com/dotnet/dotnet

• Subscription: f397515e-5b6d-41a0-b579-e190c2e3bca2
• Build: 20260710.11 (322464)
• Date Produced: July 10, 2026 10:06:10 PM UTC
• Commit: 50dbab4de210e882172b07934e9666313b7065f1
• Branch: main

• Dependency Updates:
  • From 11.0.0-beta.26355.102 to 11.0.0-beta.26360.111
    • Microsoft.DotNet.Arcade.Sdk
    • Microsoft.DotNet.Build.Tasks.Feed
  • From 0.11.5-preview.26355.102 to 0.11.5-preview.26360.111
    • Microsoft.DotNet.Cecil
  • From 11.0.0-preview.7.26355.102 to 11.0.0-preview.7.26360.111
    • Microsoft.NET.ILLink
    • Microsoft.NETCore.App.Ref
  • From 11.0.100-preview.7.26355.102 to 11.0.100-preview.7.26360.111
    • Microsoft.NET.Sdk
    • Microsoft.TemplateEngine.Authoring.Tasks

[simonrozsival]

⚠️ CI is red — a real regression from this bump, not flaky tests

I triaged build #1506104. 44 of the 46 failed tests share one deterministic root cause (every MSBuild lane, all OSes, all runtimes); only 2 are genuine flakes. I can't approve until this is resolved, so writing up everything I found and leaving the fix to you, @jonathanpeppers.

Root cause: multithreaded-MSBuild-task path resolution

Every failing lane dies during NuGet restore:

.../dotnet/sdk/11.0.100-preview.7.26360.111/NuGet.targets(571,5):
error MSB3202: The project file "…" was not found.

That SDK version (…26360.111) is exactly what this PR bumps Microsoft.NET.Sdk to (from …26355.102). Tracing it:

• NuGet.targets(571) is byte-identical across the bump — it's just <MSBuild Projects="@(…)" …/>, so MSB3202 fires because the resolved project path is wrong/absent.
• The resolver GetRestoreProjectReferencesTask now computes paths via Path.GetFullPath(TaskEnvironment.GetAbsolutePath(Path.Combine(parentDirectory, itemSpec))) — the new multithreaded task (IMultiThreadableTask / TaskEnvironment) path, which resolves relative paths against the project directory, not the process current directory. NuGet's own new test names it: Execute_RelativePaths_ResolvesAgainstProjectDirectoryNotCurrentDirectory.
• Delivered in the single dotnet/dotnet compare from the PR description (b4b350a66e...50dbab4de2): MSBuild's TaskEnvironment infra (dotnet/msbuild, VMR [release/7.0.1xx] Update dependencies from dotnet/installer #7612 — adds MultiThreadedTaskEnvironmentDriver.cs) + NuGet opting restore tasks into it (nuget/nuget.client, VMR Binary serialization compiles, but throws exception in runtime #7606). (VMR merge topology makes pinning one commit imprecise; the feature is unambiguous.)

The failures split into two groups

Group A — bugs in our own test code (only ever worked by accident; the stricter resolution exposed them):

Test	Problem	Suggested fix
BuildTest.BuildApplicationWithSpacesInPath	Reference built from the absolute folderName with a ..\ prefix (BuildTest.cs:658: $"..\\{folderName}Library1\\Library1.csproj") → normalizes to a doubled path	Use a relative path: $"..\\{TestName}Library1\\Library1.csproj"
BuildAssetsTest.FullPrefixRaisesError	App references ..\Library1\Library1.csproj, but no Library1 project exists in that test (BuildAssetsTest.cs:196); restore fails on the dangling ref before the expected XA1041	Drop the bogus ProjectReference (test is about MonoAndroidAssetsPrefix)

Fixing these two clears the bulk of the red (BuildApplicationWithSpacesInPath is by far the most frequent, retried 8× per lane).

Group B — a genuine behavior change (needs your call, please don't just patch the tests):

IncrementalBuildTest.MissingProjectReference, BuildWithLibraryTests.BuildWithNativeLibraries, and BindingBuildTest.AndroidMavenLibrary_AllDependenciesAreVerified all reference a project whose .csproj isn't on disk at restore time (by design / build-ordering — e.g. MissingProjectReference builds the app before the lib to assert the warning MSB9008 → CS0246 contract; BuildWithNativeLibraries builds Library2 before Library1).

Old SDK tolerated this → build warning MSB9008. New SDK → hard restore error MSB3202. The resolved path is correct; the file is just legitimately absent. That MSB9008→MSB3202 shift is a long-standing MSBuild behavior changing, and it looks like an unintended side-effect (NuGet's change is about relative-path resolution, not failing on missing projects). Reordering builds or asserting MSB3202 would mask a regression that could hit real customers (generated / conditional / out-of-order ProjectReferences), so this probably wants a minimal upstream repro + ruling (dotnet/sdk or NuGet/Home) before we touch the tests.

Not gating (safe to ignore for this PR)

• AndroidMessageHandlerTests.ServerCertificateCustomValidationCallback_{Approve,Reject}Request — flaky emulator DNS (Unable to resolve host "www.microsoft.com" … android_getaddrinfo failed: EAI_NODATA); "callback hasn't been called" is downstream of the same DNS failure.
• MSBuild+Emulator 6 180-min timeout — continueOnError device lane; an Auto-Retry re-ran a few device tests that failed to launch (~11 min each) until the cap. Secondary to the build break.

TL;DR

Group A = two quick test fixes on our side. Group B = a real MSB9008→MSB3202 restore behavior change that I think warrants an upstream repro/ruling rather than test edits. Over to you, @jonathanpeppers — happy to help with either once you decide the direction.