You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[.NET 10] investigate how to ship fewer copies of Mono.Android.dll #9606
Where the last four are identical, because it's managed code and not tied to a RID at all. Ideally, we could reduce this to 1 ref assembly and 1 runtime assembly.
This is going to get even worse if we support multiple runtimes in the future: NativeAOT, etc.
changed the title [-][.NET 10] investigate how to ship less copies of `Mono.Android.dll`[/-][+][.NET 10] investigate how to ship fewer copies of `Mono.Android.dll`[/+]on Dec 11, 2024
I thought I had asked/commented somewhere, "Is there a reason for us to have per-RID binaries?" Alas, I can't find me actually asking that, but it's still pertinent.
After some discussions with Peppers, we thought of a reason to have per-RID binaries: ReadyToRun places native code within the assembly, and we may want to provide ReadyToRun images within Java.Interop.dll and Mono.Android.dll to assist app startup times even in Debug configurations.
Meaning we probably will want per-RID copies of assemblies.
What needs exploration is whether each separate supported runtime will require different per-RID assemblies. If we assume builds of Mono.Android.dll for android-arm, android-arm64, android-x86, android-x64, and that each such build contains a ReadyToRun image, can that same binary assembly used by all of MonoVM, CoreCLR, and NativeAOT? If yes, then we can continue to ship 5 copies, and not (4 {RIDs} * 3 {runtimes})+1 = 13 copies.
Improvements were made for this in #10038, though the questions/concerns raised in #9606 (comment) may warrent some additional investigation in the future.
Activity
[-][.NET 10] investigate how to ship less copies of `Mono.Android.dll`[/-][+][.NET 10] investigate how to ship fewer copies of `Mono.Android.dll`[/+]jpobst commentedon Dec 11, 2024
Also with Google now releasing APIs twice a year, it's going to get worse due to supporting multiple API Levels per .NET version.
jonpryor commentedon Jan 15, 2025
I thought I had asked/commented somewhere, "Is there a reason for us to have per-RID binaries?" Alas, I can't find me actually asking that, but it's still pertinent.
After some discussions with Peppers, we thought of a reason to have per-RID binaries: ReadyToRun places native code within the assembly, and we may want to provide ReadyToRun images within
Java.Interop.dllandMono.Android.dllto assist app startup times even in Debug configurations.Meaning we probably will want per-RID copies of assemblies.
What needs exploration is whether each separate supported runtime will require different per-RID assemblies. If we assume builds of
Mono.Android.dllfor android-arm, android-arm64, android-x86, android-x64, and that each such build contains a ReadyToRun image, can that same binary assembly used by all of MonoVM, CoreCLR, and NativeAOT? If yes, then we can continue to ship 5 copies, and not (4 {RIDs} * 3 {runtimes})+1 = 13 copies.pjcollins commentedon May 28, 2025
Improvements were made for this in #10038, though the questions/concerns raised in #9606 (comment) may warrent some additional investigation in the future.