Deprecated; see https://aka.ms/dotnet-discord, and please use use #android on the DotNetEvolution Discord
I'm sure I am the only one who actually did it in the past here :p
@0xFireball: primarily, Xamarin.Android apps are linked, so if the assembly you're loading has any references to types/members which were removed....well, you can't load it. :-)
@0xFireball: if you're loading an assembly that isn't distributed *in your
.apk, then it can't realistically reference Android assets, resources, or contain Java.Lang.Object subclasses, as those required assets won't be available at runtime.
@jonpryor How do you think? xamarin/xamarin-android#124
asked on the PR
thanks for the information @jonpryor , @atsushieno
I wanted to use Assembly.Load from .NET assemblies compiled on Windows/Linux. I am aware of the linker (I have firsthand experience with linker headache, i did not realize it existed :P)
I remember getting a compile error with IronPython though, i'll post it a little later.
I was going to load assemblies not in my APK, but from the sdcard external storage
also, would roslyn compilation and execution work?
any other issues i might encounter?
As I mentioned earlier, you wouldn't be able to dynamically create Java objects (anything derived from Java.Lang.Object) as they most likely need corresponding Java classes that may be called by Android framework.
that might be a question for your Twitter followers
...though we did have someone, impressively enough
i wonder what distro he was on.
not many. :-D
@0xFireball: so long as you're not extending Java.Lang.Object/Java.Lang.Throwable -- directly or indirectly -- generating and loading IL should be fine, afaik.
so your IronPython/whatever case doesn't sound entirely implausible
the linker will be a worry, but disabling it might be a viable solution for your use case.
(I'm not sure what your use case is, but disabling the linker might be useful ;-)
otherwise, they will be linked
@jonpryor why do you think AndroidApiLevel is configurable? https://github.com/xamarin/xamarin-android/blame/master/Configuration.Override.props.in#L5
It isn't
If you set lower API Level, anything that depends on ANDROID_23 will not build
e.g. MSBuild tasks
I'm going to have to make changes to it to 24 because otherwise this is impossible. https://bugzilla.xamarin.com/show_bug.cgi?id=39984
(oops, that was private bug on N attribute support.)
Hmm, so, at this state this is going to need silly set of PRs: to add new manifest attributes, Java.Interop/src/Xamarin.Android.NamingCustomAttributes/~/{AttributeTypes}.cs will be changed (PR-2). But To make it build-able, xamarin-android needs AndroidApiLevel change from 23 to 24 (PR-1). Then xamarin-android needs additional changes to src/Xamarin.Android.Build.Tasks/Mono.Android/~Attribute.Partial.cs to actually take effect (PR-3). And our product code also needs changes (PR-4+?)
And at this state I haven't even bothered about <layout> element. It's already too much of the changes (also I have been waiting for too many PRs being merged, cannot really manage more)
@atsushieno: I'm confused by your mention of
$(AndroidApiLevel) and src/Xamarin.Android.Build.Tasks. The latter only uses $(AndroidApiLevel) to find the generated sources from src/Mono.Android; it has no impact on whether e.g. ANDROID_23 is defined within compilation of src/Xamarin.Android.Build.Tasks.
i'm kinda surprised that
src/Xamarin.Android.Build.Tasks doesn't already have a $(DefineConstants) which includes ANDROID_23 and company.
