[Java.Interop.Tools.Cecil] Fix retry logic in ReadAssembly to skip symbol loading

[jonathanpeppers]

Summary

The retry path in DirectoryAssemblyResolver.ReadAssembly was broken - it set reader_parameters.ReadSymbols = false but LoadFromMemoryMappedFile checked the instance field loadDebugSymbols instead, so the retry would re-open the same locked PDB file and throw the same IOException.

Problem

When a PDB file in the NuGet cache is locked by another process (e.g. the .NET SDK trimmer running concurrently), LoadSymbols throws an IOException. The ReadAssembly method has a catch block that is supposed to retry without symbols, but the retry calls LoadFromMemoryMappedFile which checks loadDebugSymbols (always true) and calls LoadSymbols again - hitting the same locked file.

This causes error XAPTP7000 / XA0009 build failures:

error XAPTP7000: error XA0009: Error while loading assembly: 'Xamarin.AndroidX.Core.dll'.
   ---> System.IO.IOException: The process cannot access the file 'Xamarin.AndroidX.Core.pdb'
        because it is being used by another process.

Fix

Add an explicit bool loadSymbols parameter to LoadFromMemoryMappedFile so the retry can pass false to actually skip symbol loading.

Context: dotnet/android#11081

[Copilot]

Pull request overview

Fixes DirectoryAssemblyResolver.ReadAssembly() retry behavior in Java.Interop.Tools.Cecil so that when the initial read fails due to locked PDB/symbol loading, the retry actually skips symbol loading instead of re-attempting the same failing path (addressing build failures like XA0009/XAPTP7000 reported in dotnet/android#11081).

Changes:

• Thread a new bool loadSymbols parameter through LoadFromMemoryMappedFile() to explicitly control whether symbols are loaded.
• Update the retry path in ReadAssembly() to call LoadFromMemoryMappedFile(..., loadSymbols: false) after a failure when loading with symbols.

[jonathanpeppers]

🤖 AI Review Summary

Verdict: ✅ LGTM (pending CI)

Found 0 issues, 1 suggestion:

• 💡 Testing: Consider adding a regression test for the locked-PDB retry path (DirectoryAssemblyResolverTests.cs)

Analysis

The bug is real and well-explained: LoadFromMemoryMappedFile checked the instance field loadDebugSymbols instead of respecting the caller's intent, so the retry path in ReadAssembly re-opened the same locked PDB and threw the same IOException.

The fix correctly threads a bool loadSymbols parameter through LoadFromMemoryMappedFile so the retry can pass false to actually skip symbol loading. The if (!loadDebugSymbols) throw; guard is a nice defensive addition — if we're not loading symbols in the first place, there's nothing to retry.

👍 Clean, minimal fix that addresses root cause rather than symptoms. Good PR description with clear problem/fix separation.

⚠️ CI note: The Azure DevOps dotnet.java-interop pipeline is still queued. LGTM is conditional on CI passing.

---

Review generated by android-reviewer from review guidelines.