Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jonathan Pryor
    @jonpryor
    asked on the PR
    Atsushi Eno
    @atsushieno
    yup
    Atsushi Eno
    @atsushieno
    okay, I will continue tomorrow.
    0xFireball
    @0xFireball

    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?

    Atsushi Eno
    @atsushieno
    I never tried that. Roslyn itself is IIRC i some PCL profile, hopefully it compiles and runs on X.A. profile?
    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.
    Marek Habersack
    @grendello
    are there any folks around who use Linux distros not derived from Debian or Ubuntu?
    Jonathan Pryor
    @jonpryor
    @grendello: on this channel? :-)
    that might be a question for your Twitter followers
    Marek Habersack
    @grendello
    hopefully on this channel :)
    Jonathan Pryor
    @jonpryor
    that's hilarious
    Marek Habersack
    @grendello
    my Twitter followers are probably all OSX or Windows users :D
    Jonathan Pryor
    @jonpryor
    we barely even work on Linux, and you expect anyone using Linux here?
    ...though we did have someone, impressively enough
    i wonder what distro he was on.
    Marek Habersack
    @grendello
    we had people here contributing to Linux
    Jonathan Pryor
    @jonpryor
    yeah. one?
    not many. :-D
    Marek Habersack
    @grendello
    well, that's 50% of our contributors :)
    Jonathan Pryor
    @jonpryor
    @0xFireball: linker-wise, so long as everything you need is referenced in the .apk, you shouldn't need to worry. Though if you're doing an IDE/toolchain, you might want to just disable linking...
    @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 ;-)
    Atsushi Eno
    @atsushieno
    xamarin/xamarin-android#127 - you cannot just change v6.0.99 to v7.0 without changing this code.
    0xFireball
    @0xFireball
    @jonpryor Without linking, my APK blows up to 30+ MB because of Xamarin.Android.dll, which is by far the largest assembly in the APK. Instead of that, wouldn't it be better to link only that assembly, especially if dynamic calling of android code is implausible?
    Atsushi Eno
    @atsushieno
    There is LinkSdkOnly mode which is exactly for that purpose
    0xFireball
    @0xFireball
    @atsushieno , yes, i am aware of that, but i want to expose mscorlib and System.Core. Would adding those to the list to skip work?
    Atsushi Eno
    @atsushieno
    If you list them in LinkDescription file yeah they should be skipped (preserved)
    otherwise, they will be linked
    Atsushi Eno
    @atsushieno
    @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.)
    Atsushi Eno
    @atsushieno
    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)
    Atsushi Eno
    @atsushieno
    k, they all need to be merged xamarin/java.interop#56 xamarin/xamarin-android#128 xamarin/xamarin-android#127
    Jonathan Pryor
    @jonpryor
    @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.
    MakarkinPRO
    @MakarkinPRO
    have a issue
    blob
    Jonathan Pryor
    @jonpryor
    @MakarkinPRO: that's a warning message, not an error
    looks like two different assemblies are binding the same Java types
    which will result in no end of confusion
    MakarkinPRO
    @MakarkinPRO
    blob
    @jonpryor this is error
    any ideas of what can I do
    ?