Skip to content

Enable R2R when publishing with custom Configuration value for CoreCLR#11071

Closed
Copilot wants to merge 4 commits into
mainfrom
copilot/enable-r2r-custom-configuration
Closed

Enable R2R when publishing with custom Configuration value for CoreCLR#11071
Copilot wants to merge 4 commits into
mainfrom
copilot/enable-r2r-custom-configuration

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Apr 2, 2026

CoreCLR R2R was only enabled when Configuration == 'Release', so customers using custom configuration values (e.g. dotnet publish -c MyRelease) got no R2R optimization.

Changes

  • Microsoft.Android.Sdk.CoreCLR.targets: Changed R2R enablement condition from Configuration == 'Release' to Configuration != 'Debug', so R2R is enabled for any non-Debug configuration (including custom ones like CustomRelease):
    <PublishReadyToRun Condition=" '$(PublishReadyToRun)' == '' and '$(Configuration)' != 'Debug' ">true</PublishReadyToRun>
  • XASdkTests.cs: Add DotNetPublishReadyToRunCustomConfiguration end-to-end test — creates a project with releaseConfigurationName: "CustomRelease", calls DotNetCLI.Publish with Configuration=CustomRelease, then verifies the produced APK contains R2R data via PE header inspection.

Update the PublishReadyToRun condition in Microsoft.Android.Sdk.CoreCLR.targets
to also check _IsPublishing, so R2R is enabled either when Configuration is
Release OR when the project is being published via dotnet publish.

This fixes the scenario where customers use custom Configuration values
(e.g. dotnet publish -c MyCustomConfig) and R2R was not enabled for CoreCLR.

Fixes #9944

Agent-Logs-Url: https://github.com/dotnet/android/sessions/09eff3bb-5a27-4d30-9025-395f55206033

Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>
Copilot AI changed the title [WIP] Enable R2R when publishing with custom Configuration value Enable R2R when publishing with custom Configuration value for CoreCLR Apr 2, 2026
Copilot AI requested a review from simonrozsival April 2, 2026 09:33
@simonrozsival simonrozsival marked this pull request as ready for review May 7, 2026 09:27
Copilot AI review requested due to automatic review settings May 7, 2026 09:27
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Enables CoreCLR ReadyToRun (R2R) by default when building an Android application via dotnet publish, even if the user supplies a non-standard $(Configuration) name (e.g. -c CustomRelease), aligning publish-time optimization behavior with customer expectations.

Changes:

  • Update CoreCLR targets to default PublishReadyToRun=true when publishing ($(_IsPublishing)==true) even if $(Configuration) != Release.
  • Add a new test intended to validate R2R output for a custom release configuration name.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/BuildTest2.cs Adds a test covering the “custom Configuration + publishing” scenario for CoreCLR R2R.
src/Xamarin.Android.Build.Tasks/Microsoft.Android.Sdk/targets/Microsoft.Android.Sdk.CoreCLR.targets Extends default R2R enablement to publishing builds independent of configuration name.

Comment thread src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/BuildTest2.cs Outdated
Comment thread src/Xamarin.Android.Build.Tasks/Tests/Xamarin.Android.Build.Tests/BuildTest2.cs Outdated
Replace the test that set _IsPublishing directly with an end-to-end
test in XASdkTests that calls DotNetCLI.Publish with
Configuration=CustomRelease, then verifies the produced APK contains
R2R data via PE header inspection.

Agent-Logs-Url: https://github.com/dotnet/android/sessions/0ec75c40-8151-4570-84dc-84db66c5d887

Co-authored-by: jonathanpeppers <840039+jonathanpeppers@users.noreply.github.com>
proj.SetProperty (KnownProperties.RuntimeIdentifier, runtimeIdentifier);
proj.SetProperty ("AndroidEnableAssemblyCompression", "false");

var builder = CreateDllBuilder ();
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot why does this call CreateDllBuilder()? should it be CreateApkBuilder() for an application project?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It follows the pattern used by the other tests in this file (DotNetPublishDefaultValues at line 277, DotNetPublish at line 352, etc.) — the builder is only used to save the project to disk via builder.Save(proj), and the actual publish is done through DotNetCLI.Publish(). All tests in XASdkTests.cs use CreateDllBuilder() for this purpose. Happy to change it if you'd prefer a different approach though.

@simonrozsival
Copy link
Copy Markdown
Member

@copilot the new test fails on all platforms - Windows, Linux, and macOS. Revisit what causes the build to fail and properly implement the support for custom configurations. I think a better way than looking for $(_IsPublishing) is looking for Debug build specifics:

DotNetPublishReadyToRunCustomConfiguration

dotnet publish -c CustomRelease should succeed
Expected: True
But was:  False

…ustom releaseConfigurationName

Agent-Logs-Url: https://github.com/dotnet/android/sessions/ee831029-5646-4522-a3fe-07982eca2c6c

Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>
Copy link
Copy Markdown
Contributor Author

Copilot AI commented May 11, 2026

@copilot the new test fails on all platforms - Windows, Linux, and macOS. Revisit what causes the build to fail and properly implement the support for custom configurations. I think a better way than ...

Fixed in 1540d65. Two changes:

  1. CoreCLR.targets: Changed condition from '$(Configuration)' == 'Release' or '$(_IsPublishing)' == 'true' to '$(Configuration)' != 'Debug' — R2R is now enabled for any non-Debug configuration without relying on _IsPublishing.

  2. Test: The project was created with default config names (Debug/Release), so passing Configuration=CustomRelease didn't match any configuration-specific properties in the .csproj. Fixed by using new XamarinAndroidApplicationProject(releaseConfigurationName: "CustomRelease") { IsRelease = true } so the generated .csproj has the proper CustomRelease configuration group.

Comment on lines -16 to +17
<!-- Default to R2R Composite for CoreCLR Release mode -->
<PublishReadyToRun Condition=" '$(PublishReadyToRun)' == '' and '$(Configuration)' == 'Release' ">true</PublishReadyToRun>
<!-- Default to R2R Composite for CoreCLR in any non-Debug configuration -->
<PublishReadyToRun Condition=" '$(PublishReadyToRun)' == '' and '$(Configuration)' != 'Debug' ">true</PublishReadyToRun>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if they name their configuration DebugProd or DebugAppStore?

Related to:

I wonder if we should actually address the root cause in .NET SDK and not change this yet?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if they name their configuration DebugProd or DebugAppStore?

Yeah, good point.

I wonder if we should actually address the root cause in .NET SDK and not change this yet?

Ideally, yes. Let's close this PR now and let's revisit the issue later.

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.

[CoreCLR] Enable R2R when publishing with custom Configuration value

4 participants