Enable R2R when publishing with custom Configuration value for CoreCLR#11071
Enable R2R when publishing with custom Configuration value for CoreCLR#11071
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.
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: Add_IsPublishingcheck so R2R is enabled during anydotnet publish, regardless of configuration name:XASdkTests.cs: AddDotNetPublishReadyToRunCustomConfigurationend-to-end test — callsDotNetCLI.PublishwithConfiguration=CustomRelease, then verifies the produced APK contains R2R data via PE header inspection.