Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[One .NET] better logic for deduplication of architecture-specific as…
…semblies (#5276) Fixes: #5263 In .NET 6, we currently run the `ILLink` MSBuild target for each `$(RuntimeIdentifier)`, as the Mono runtime packs have some .NET assemblies that differ per architecture. To make this happen, the `<ProcessAssemblies/>` task (51fb93e) works with inputs such as: * `android.21-arm\linked\Foo.dll` * `android.21-x86\linked\Foo.dll` * `android.21-arm\linked\System.Private.CoreLib.dll` * `android.21-x86\linked\System.Private.CoreLib.dll` and "merges" this to what we need in the output of the `.apk`: * `assemblies/Foo.dll` * `assemblies/armeabi-v7a/System.Private.CoreLib.dll` * `assemblies/x86/System.Private.CoreLib.dll` `Foo.dll` is identical for all architectures, so we only need to use a single copy of it. A bug in our implementation was for an assembly that differed between 32-bit and 64-bit platforms, but was identical within those sets: * `android.21-arm\linked\System.Collections.Concurrent.dll` * `android.21-x86\linked\System.Collections.Concurrent.dll` * `android.21-arm64\linked\System.Collections.Concurrent.dll` The `-arm` and `-x86` copies of these assemblies have the same MVID. The `<ProcessAssemblies/>` task would *skip* processing any assembly with a previously "seen" MVID. Consequently, the `.apk` contained: * `assemblies/armeabi-v7a/System.Collections.Concurrent.dll` * `assemblies/arm64-v8a/System.Collections.Concurrent.dll` Notably absent was a copy in `assemblies/x86`. The result was a runtime crash when running on the x86 emulator: Unhandled Exception: System.TypeLoadException: Could not set up parent class, due to: Could not load type of field 'Java.Interop.JniRuntime:TrackedInstances' (31) due to: Could not load file or assembly 'System.Collections.Concurrent, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. assembly:Java.Interop.dll type:JniRuntime member:(null) I reworked the logic to instead do: * Group by assembly file name * Count the unique MVIDs * If we have only 1 MVID, we just need the first assembly. * Otherwise, place the assemblies in architecture-specific directories. The resulting code seems like it is a bit simpler, and likely a little faster. I was able to call `MonoAndroidHelper.HasMonoAndroidReference()` once per file name, which should help performance. I updated `XASdkTests.DotNetBuild()` to check this scenario.
- Loading branch information