Skip to content

[release/11.0.1xx-preview7] Update dependencies from dotnet/dotnet - #12249

Open
dotnet-maestro[bot] wants to merge 13 commits into
release/11.0.1xx-preview7from
darc-release/11.0.1xx-preview7-cef39228-4967-464c-895e-3f4b7109bf63
Open

[release/11.0.1xx-preview7] Update dependencies from dotnet/dotnet#12249
dotnet-maestro[bot] wants to merge 13 commits into
release/11.0.1xx-preview7from
darc-release/11.0.1xx-preview7-cef39228-4967-464c-895e-3f4b7109bf63

Conversation

@dotnet-maestro

@dotnet-maestro dotnet-maestro Bot commented Jul 28, 2026

Copy link
Copy Markdown
Contributor

This pull request updates the following dependencies

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

…726.6

On relative base path root
Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Feed From Version 11.0.0-beta.26365.101 -> To Version 11.0.0-beta.26376.106
Microsoft.DotNet.Cecil From Version 0.11.5-preview.26365.101 -> To Version 0.11.5-preview.26376.106
Microsoft.NET.ILLink , Microsoft.NETCore.App.Ref From Version 11.0.0-preview.7.26365.101 -> To Version 11.0.0-preview.7.26376.106
Microsoft.NET.Sdk , Microsoft.TemplateEngine.Authoring.Tasks From Version 11.0.100-preview.7.26365.101 -> To Version 11.0.100-preview.7.26376.106
Context: dotnet/sdk#53715

Starting with `11.0.100-preview.7.26376.106`, the .NET SDK emits a
`<App>.runtimeconfig.dev.json` file for `Debug` builds containing the
Hot Reload feature switches:

    {
      "runtimeOptions": {
        "configProperties": {
          "System.Reflection.Metadata.MetadataUpdater.IsSupported": true,
          "System.StartupHookProvider.IsSupported": true
        }
      }
    }

`hostfxr` layers this file on top of `*.runtimeconfig.json` at startup,
but .NET for Android does not use `hostfxr`: it bakes the runtime
properties into the application at build time. So the file was simply
ignored, and the switches never reached the app.

Do the same layering at build time for CoreCLR: read the dev file after
`*.runtimeconfig.json` in `RuntimePropertiesParser`, so its
`configProperties` win. This matches what Blazor WebAssembly does in
dotnet/runtime#130825.

This does not conflict with the switches we set ourselves.
`$(StartupHookSupport)` is only set to `false` when
`'$(Optimize)' == 'true'`, and the SDK only generates the dev file for
`Debug` builds, so the two are disjoint in practice. We never set
`$(MetadataUpdaterSupport)`.

Mono is unchanged: it reads runtime properties from the `rc.bin` blob
produced by `RuntimeConfigParserTask`, which only accepts a single input
file. Teaching that task about multiple files requires a change in
dotnet/runtime.

While here, add both `runtimeconfig` files to
`_GetGeneratePackageManagerJavaInputs`. Neither was an input before, so
editing them would not trigger a rebuild.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b158ad70-1e5e-44cd-a1f2-60353f3bb560
`String.IsNullOrEmpty()` is not NRT annotated in `netstandard2.0`, so the
compiler could not tell that `projectRuntimeConfigDevFilePath` is not
`null` inside the `if`. Use our own `IsNullOrEmpty()` extension method,
which is annotated with `[NotNullWhen (false)]`.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b158ad70-1e5e-44cd-a1f2-60353f3bb560
jonathanpeppers and others added 10 commits July 28, 2026 13:37
Context: #12254

Starting with .NET SDK `11.0.100-preview.7.26376.106`, `dotnet test` is
device-aware: it selects a device with `ComputeAvailableDevices`, then
deploys with `DeployToDevice` and computes the launch command with
`ComputeRunArguments`. Those are separate `ProjectInstance.Build ()`
calls against the same `ProjectInstance`, so `ProcessFrameworkReferences`
runs twice. MSBuild task outputs append, so `@(ResolvedRuntimePack)` ends
up with two `Microsoft.NETCore.App` entries and `ResolveFrameworkReferences`
throws:

    error MSB4018: The "ResolveFrameworkReferences" task failed unexpectedly.
    System.ArgumentException: An item with the same key has already been added. Key: Microsoft.NETCore.App

This reproduces with a stock SDK and the released
`Microsoft.Android.Sdk.Windows` `37.0.0-preview.6.59`, so it is not
caused by anything in this repo. Pinning a single
`$(RuntimeIdentifier)` does not help, and `dotnet run` works on the same
project, so there is nothing we can do from our targets. Ignore the
`dotnet test` cases until the fix flows back from dotnet/sdk.

The `dotnet run` case is unaffected and stays enabled.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b158ad70-1e5e-44cd-a1f2-60353f3bb560
…728.6

On relative base path root
Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Feed From Version 11.0.0-beta.26365.101 -> To Version 11.0.0-beta.26378.106
Microsoft.DotNet.Cecil From Version 0.11.5-preview.26365.101 -> To Version 0.11.5-preview.26378.106
Microsoft.NET.ILLink , Microsoft.NETCore.App.Ref From Version 11.0.0-preview.7.26365.101 -> To Version 11.0.0-preview.7.26378.106
Microsoft.NET.Sdk , Microsoft.TemplateEngine.Authoring.Tasks From Version 11.0.100-preview.7.26365.101 -> To Version 11.0.100-preview.7.26378.106
`dotnet test` currently fails to deploy to a device, so every APK
instrumentation lane fails with "Deployment to device failed. Fix any
deployment errors and run again." See #12254.

Drive the instrumentation with `dotnet run` instead. We do not lose the
test report: the on-device runner writes its own TRX and reports the
location back through the instrumentation bundle as
`INSTRUMENTATION_RESULT: resultsPath=<device path>`. `dotnet run` invokes
`adb shell am instrument -w`, which prints that bundle, so the path can be
scraped and the TRX pulled to where `PublishTestResults` expects it.

No product code changes; revert to `dotnet test` once the SDK fix lands.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b158ad70-1e5e-44cd-a1f2-60353f3bb560
BuildTestJarFile writes the test JAR to Jars\ inside the project directory.
The .NET Android SDK's default @(AndroidLibrary) glob is `**\*.jar` and
%(Bind) defaults to true, so once that file exists on disk any subsequent
evaluation of the project picks it up as a JAR to bind.

That does not happen during a plain `-t:Install` build, because the JAR is
produced by the same build that globbed for it. It does happen on the second
MSBuild submission that `dotnet test` / `dotnet run` make when deploying to a
device: the JAR is already on disk, gets bound, and the generated
Net.Dot.Jni.Test.* sources fail to compile with CS0108/CS0114/CS0436. That is
fatal here because this project sets TreatWarningsAsErrors=true, and it
surfaces only as the generic "Deployment to device failed" message, taking
out every APK instrumentation lane.

Remove the JAR from @(AndroidLibrary); it is already included explicitly as
@(AndroidJavaLibrary), which packages it without binding it.

See #12254.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b158ad70-1e5e-44cd-a1f2-60353f3bb560
Use the exact JAR file names rather than `Jars\**\*.jar`. Both the
non-trimmable and trimmable variants are listed, since a single job builds
several test configurations in one workspace and the two can coexist.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b158ad70-1e5e-44cd-a1f2-60353f3bb560
`dotnet run` deploys to a device using an in-process MSBuild, bypassing the
`MSBuildForwardingApp` that normally sets `DOTNET_HOST_PATH`. MSBuild needs
that variable to bootstrap task hosts, so ILLink's `ComputeManagedAssemblies`
(`Runtime="NET"`) failed with:

    error MSB4221: Could not run the "ComputeManagedAssemblies" task because
    MSBuild could not create or connect to a task host with runtime "NET" and
    architecture "x64" ... DOTNET_HOST_PATH is not set.

Set it explicitly to the same `dotnet` we invoke.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b158ad70-1e5e-44cd-a1f2-60353f3bb560
Drop the separate `-t:Install` build step. `dotnet run` builds, installs
and runs in one invocation.

The two-step shape was broken: `_CollectJavaSourceForBinding` and
`_CompileBindingJava` only run as part of `Build`, so when the deploy pass
rebuilt anything it re-ran `_CompileJava` without the binding classes jar on
javac's classpath, producing `XAJVC0000: cannot find symbol`.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b158ad70-1e5e-44cd-a1f2-60353f3bb560
…728.19

On relative base path root
Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.Build.Tasks.Feed From Version 11.0.0-beta.26365.101 -> To Version 11.0.0-beta.26378.119
Microsoft.DotNet.Cecil From Version 0.11.5-preview.26365.101 -> To Version 0.11.5-preview.26378.119
Microsoft.NET.ILLink , Microsoft.NETCore.App.Ref From Version 11.0.0-preview.7.26365.101 -> To Version 11.0.0-preview.7.26378.119
Microsoft.NET.Sdk , Microsoft.TemplateEngine.Authoring.Tasks From Version 11.0.100-preview.7.26365.101 -> To Version 11.0.100-preview.7.26378.119
APKs 2 builds the same project six times with different settings in a shared
workspace. `-t:Clean` does not remove enough, so each lane starts on top of the
previous lane's output. Wipe obj/bin under tests/ before each lane instead.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: b158ad70-1e5e-44cd-a1f2-60353f3bb560
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant