Enable R2R when publishing with custom Configuration value for CoreCLR#11071
Enable R2R when publishing with custom Configuration value for CoreCLR#11071Copilot wants to merge 4 commits into
Conversation
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>
There was a problem hiding this comment.
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=truewhen 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. |
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 (); |
There was a problem hiding this comment.
@copilot why does this call CreateDllBuilder()? should it be CreateApkBuilder() for an application project?
There was a problem hiding this comment.
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.
|
@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 |
…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>
Fixed in 1540d65. Two changes:
|
| <!-- 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> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
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 fromConfiguration == 'Release'toConfiguration != 'Debug', so R2R is enabled for any non-Debug configuration (including custom ones likeCustomRelease):XASdkTests.cs: AddDotNetPublishReadyToRunCustomConfigurationend-to-end test — creates a project withreleaseConfigurationName: "CustomRelease", callsDotNetCLI.PublishwithConfiguration=CustomRelease, then verifies the produced APK contains R2R data via PE header inspection.