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
    System.Drawing.Primitives.dll is a new assembly required to support .NET Standard 1.6 (?)
    it contains things like Size and Point, which we already defined in Mono.Android.dll
    thus we need type forwards so that it actually works
    Atsushi Eno
    @atsushieno
    So the situation was like, there used to be implementation-based S.D.Primitives.dll in the last mono reference when I built xamarin-android
    and the latest mono-4.6.0-branch doesn't have it anymore, fixed to become type forwarders.
    Jonathan Pryor
    @jonpryor
    and it works for me because i'm building with mono 4.4, not 4.6...?
    Atsushi Eno
    @atsushieno
    But the old dll interfered with the build target.
    At this state I don't think system mono matters
    The types conflicted within bin/Debug/lib/xbuild-frameworks
    Is your System.Drawing.Primitives.dll already set of type forwarders?
    Jonathan Pryor
    @jonpryor
    it only contains type forwarders
    Atsushi Eno
    @atsushieno
    If not, we'll still have to bump mono
    ok, then no need
    atsushieno @atsushieno hopes he can just go back to the old mono without trouble
    Atsushi Eno
    @atsushieno
    Nah, current external/mono fails to build
    xamarin/xamarin-android#123
    could anyone merge it?
    Alexander Köplinger
    @akoeplinger
    that makes sense. I think there was a short period of time where we built System.Drawing.Primitives.dll which contained no type forwarders, but the actual types inside it. then we realized this won't work on mobile and changed it to contain forwarders
    or rather, to not build it for mobile as part of mono build, since the products need to build it instead to have the correct references etc
    Jonathan Pryor
    @jonpryor
    that makes sense...
    0xFireball
    @0xFireball
    does dynamic code loading from assemblies at runtime work on Xamarin.Android?
    For example, loading a type and creating an instance?
    Atsushi Eno
    @atsushieno
    "DLR" works. Dynamically generating Java types is different question, you'd need very tricky approach to achieve that.
    e.g. bundle "dx" within the app itself and make use of it. That's not for normal developers.
    I'm sure I am the only one who actually did it in the past here :p
    Jonathan Pryor
    @jonpryor
    @0xFireball: Assembly.Load() can work...but it has various issues.
    @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.
    Atsushi Eno
    @atsushieno
    oops yeah dynamic code gen is too much. It was just about reflection.
    @jonpryor How do you think? xamarin/xamarin-android#124
    Jonathan Pryor
    @jonpryor
    @atsushieno: I have a question on it. ;-)
    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...