Repository navigation
Need to support per-ABI mscorlib.dll files #4337
Description
As part of the .NET 5 effort, the dotnet/runtime-based mono runtime will support (require?) per-ABI mscorlib.dll files: different files will be used between 32-bit and 64-bit environments and between ARM vs. x86.
Supporting this will require changing at least four separate areas:
-
Installation: we can no longer have just
xbuild-frameworks/MonoAndroid/v1.0/mscorlib.dll, but will presumably havexbuild/Xamarin/Android/lib/x86/bcl/mscorlib.dll/etc., one per ABI. -
Build: Which
mscorlib.dllis used for build purposes? Presumably we'd have to preservexbuild-frameworks/MonoAndroid/v1.0/mscorlib.dlland have it either be a copy of some ABI or be a "reference assembly"? -
Packaging: The
.apk/.aabfile will need to add these per-ABImscorlib.dllfiles. How do we do that? We currently have a "flat"assemblies/directory within the.apkto store all assemblies, but that won't work as-is anymore. -
Runtime: How do we specify which
mscorlib.dllgets loaded? Is this somethinglibmonodroid.soneeds to explicitly control, or willlibmonosgen-2.0.socontrol it, or...?
Lots of unknowns.
Activity
grendello commentedon Feb 27, 2020
jonpryor commentedon Feb 27, 2020
Proposal: the
.apkcontains anassemblies/[ABI]folder, where[ABI]comes fromBasicAndroidSystem::android_abi_names: https://github.com/xamarin/xamarin-android/blob/master/src/monodroid/jni/basic-android-system.hh#L21-L25Then when looking for an assembly, we for
assemblies/[ABI]/ASSEMBLY.dllfirst before falling back toassemblies/ASSEMBLY.dll.grendello commentedon Feb 27, 2020
Do we expect to have more assemblies like
mscorlib.dll? If not, then we should just special-case it and save time on the runtimeakoeplinger commentedon Feb 27, 2020
(2) isn't your concern anymore with .NET 5. There's a reference assembly that will be used to compile the app/library code against.
marek-safar commentedon Feb 27, 2020
I think (1) installation is something what XA won't control at all
pjcollins commentedon Feb 27, 2020
The entire BCL will need to be treated in this way by my understanding, not just mscorlib.
Both 1 and 2 should be handled by the .NET Core installation / build system. At build time, our project will compile against the "reference assembly" version of these assemblies which will be resolved through the
TargetingPackportion of the Microsoft.NETCore.App FrameworkReference.This
FrameworkReferencemaps the non-RID specific reference assemblies from theTargetingPackto the correspondingRuntimePackassets based on the RID(s) specified by the project. There is an msbuild task we could potentially lean on at package time (3) to make sure we scoop up the correct runtime files on disk and put them in the correct place in the .apkI like the proposal of introducing a
assemblies/[ABI]folder, but perhaps instead of[ABI]we want to use the architecture portion of our soon to be created Android RIDs? For example,x86,x64,arm, orarm64.instead of
x86,x86_64,armeabi-v7a, orarm64-v8a.I'm not sure if that is any worse or better than the
ABIproposal, either way I think we'll need to map$(AndroidSupportedAbis)to$(RuntimeIdentifiers)in various places in our build system.akoeplinger commentedon Feb 27, 2020
No, System.Private.CoreLib.dll is the only managed assembly with this architecture-specific build right now.
grendello commentedon Feb 27, 2020
@pjcollins if we're to treat the entire BCL like this then we'll be in trouble wrt apk size for multi-arch apps. Well, I guess we're going to have a size increase problem anyway...
grendello commentedon Feb 27, 2020
@akoeplinger I guess we shouldn't assume this is going to remain unchanged... We need to come up with a mechanism that deals with it now, trying to pay as small price as possible both regarding the apk size and the runtime performance. Is there any way to tell an arch-specific assembly from a "pure" managed one?
marek-safar commentedon Feb 27, 2020
@grendello why does it matter? isn't the app bundle size not relevant?
grendello commentedon Feb 27, 2020
@marek-safar if we ship AAB then it (mostly) doesn't matter as long as Google Play Store can determine how to split it up - in this case we most probably need to put the arch-specific assemblies in the
lib/[ARCH]dir. In the case of a regular .apk, we'll be shipping everything to everybody as I don't think regular .apks are split up on upload to Play Store (but maybe I'm wrong?)marek-safar commentedon Feb 27, 2020
Is this actual problem if AAB does know how to handle it correctly?
grendello commentedon Feb 27, 2020
@marek-safar until AAB is the only way to distribute Android apps, it is a problem, yes.
marek-safar commentedon Feb 27, 2020
Why? Devs have 2 options when they target a single target and 1 option if they target more than 1 target so we have solution nonetheless
grendello commentedon Feb 27, 2020
@marek-safar Devs have 3 options: