[TrimmableTypeMap] Add trimmable DotNetRun cases#11486
Open
simonrozsival wants to merge 11 commits into
Open
Conversation
Add Release and Debug trimmable typemap coverage to the DotNetRun device integration test using CoreCLR. Fixes #11019 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
There was a problem hiding this comment.
Pull request overview
Adds trimmable typemap coverage to the DotNetRun device integration test matrix, ensuring the trimmable typemap path is exercised under CoreCLR (UseMonoRuntime=false) in both Debug and Release configurations.
Changes:
- Add Release
trimmableDotNetRun test case usingAndroidRuntime.CoreCLR. - Add Debug
trimmableDotNetRun test case usingAndroidRuntime.CoreCLR.
Add Release NativeAOT coverage for the trimmable typemap DotNetRun device integration test. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
simonrozsival
commented
May 26, 2026
Agent-Logs-Url: https://github.com/dotnet/android/sessions/9552bfeb-121e-4610-bd28-49396c6295a7 Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>
Agent-Logs-Url: https://github.com/dotnet/android/sessions/9552bfeb-121e-4610-bd28-49396c6295a7 Co-authored-by: simonrozsival <374616+simonrozsival@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
The dependabot bump (#11562) committed banned-apis.targets with CRLF bytes stored directly in the git blob. Since .gitattributes declares `*.targets eol=crlf`, the blob must be stored normalized (LF) and only converted to CRLF on checkout. The un-normalized blob caused the CI 'Ensure no modified/untracked files' check to fail because git's renormalization detection flagged the file as modified. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
…-build failure) The Debug CoreCLR trimmable DotNetRun case fails identically to the already-ignored Release case: `dotnet run --no-build` re-runs GenerateNativeApplicationConfigSources, which throws XAGCA7023 because obj/Debug/android/assets/<rid>/Mono.Android.dll is missing in the no-build incremental state. Broaden the existing ignore to cover both Debug and Release CoreCLR trimmable until the underlying no-build issue is fixed. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
The trimmable _GenerateJavaStubs target listed _CleanIntermediateIfNeeded in its DependsOnTargets. On a full build that is redundant (the target already runs early via _AndroidBuildDependsOn in BuildOrder.targets). But during an incremental deploy that does not rebuild (the Install/DeployToDevice chain used by `dotnet run` without a build), the early Build chain never executes, so this was the only invocation of _CleanIntermediateIfNeeded -- and it ran late, *after* _PrepareAssemblies had already populated obj/<config>/android/assets/<abi>/*.dll. It then deleted obj/<config>/android, and because _PrepareAssemblies had already executed it was skipped and did not recreate the assemblies. _GeneratePackageManagerJava then failed with XAGCA7023 (DirectoryNotFoundException on assets/<abi>/Mono.Android.dll). Remove _CleanIntermediateIfNeeded from the trimmable _GenerateJavaStubs DependsOnTargets so it matches the llvm-ir sibling target, which already omits it. Cleaning still happens early for full builds via BuildOrder.targets. With this fix, the trimmable DotNetRun scenarios (Debug CoreCLR, Release CoreCLR, NativeAOT) build, deploy, and launch on device, so remove the Assert.Ignore guard that skipped the CoreCLR trimmable cases. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
GenerateTrimmableTypeMap cleans the post-trim Java source output directory before copying the Java sources that remain after trimming. On CI this cleanup can fail transiently with Directory not empty while recursively deleting nested source directories, which surfaces as XAGTT7024 and fails otherwise valid CoreCLR trimmable builds. Use the same retry policy and transient error handling as RemoveDirFixed for this internal cleanup path, including access denied, sharing violation, and directory-not-empty retries. The cleanup remains strict: non-transient delete errors still fail the build. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
CoreCLR trimmable builds with multiple RuntimeIdentifiers run per-RID inner builds in parallel. Those inner builds used the outer intermediate directory for post-trim Java sources so the packaging phase could compile the shared Java output, but every RID inner build generated and cleaned the same obj/<configuration>/typemap/linked-java directory. That made the post-trim Java source generation race with itself. CI observed this as XAGTT7024 / Directory not empty while one inner build deleted the shared linked-java directory as another inner build was also using it. Retrying the recursive delete masks the symptom but leaves the shared-output race. Pass the outer RuntimeIdentifiers list into inner builds and let only the first RID inner build generate the shared post-trim Java sources. The output remains in the outer intermediate directory where _GenerateJavaStubs expects it, while parallel inner builds no longer clean or write the same directory. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
The trimmable Java sources are RID-independent, even though the linked assembly inputs are produced by per-RID inner builds. Generating those Java sources from inside the parallel RuntimeIdentifier inner builds made multiple inner builds clean and write the same outer intermediate linked-java directory. Move post-trim Java source generation to the outer build after _ResolveAssemblies has collected the per-RID ResolvedFileToPublish items. The target now runs once, uses a representative RID's linked assemblies as input for the RID-independent Java sources, and leaves the output in the outer intermediate directory where _GenerateJavaStubs expects it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
/azp run |
|
Azure Pipelines successfully started running 1 pipeline(s). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds
trimmabletypemap coverage to theDotNetRundevice integration test:UseMonoRuntime=false)UseMonoRuntime=false)Fixes #11019
Validation:
make preparegit diff --check./dotnet-local.sh build tests/MSBuildDeviceIntegration/MSBuildDeviceIntegration.csproj -c Debug --no-restore, but local validation was blocked by unrelatedbundletooljar repackaging failure (jar ... bundletool-all-1.18.3-copy.jarexited with code 1). Deferring full validation to CI.