Correct, the blog post and plan is only about the framework libraries like mscorlib.dll, System.dll that ship with Mono.
-Alex > On 30 Nov 2016, at 22:23, Eberhard Beilharz <e...@sil.org> wrote: > > I think there might be a misunderstanding. Miguel, correct me if I'm wrong. > > After reading the blog post again, I think it talks about Mono itself > having different libraries on different platforms (i.e. the framework > assemblies). This means you wouldn't be able to take System.dll built on > Linux and run it on Windows or Mac. But this applies only to the mono > installation. > > My reading of the post is that your assemblies/libraries that you > compile yourself will still be able to run on multiple platforms. > > IMO not being able to take Mono assemblies and put them on another > platform wouldn't be to much of a problem. It's nice to have, but > already we're not able to copy the runtime and unmanaged libraries from > one platform to the other, so additionally not being able to copy the > managed assemblies doesn't seem to drastic of a change. > > It would be different if we wouldn't be able to compile a library > (that's not part of mono) and use that on different platforms. That > would eliminate one of the big advantages of .NET. But I don't think the > blog post talks about that. > > Eberhard > > > On 11/30/2016 09:37 PM, Johnnie Odom wrote: >> >> I write a lot of small sysadmin utilities using Mono and one of the big >> selling points with the .NET libraries I use is that they generally do work >> across Windows/Mac/Linux without recompilation. I think the future for >> Microsoft is to be as easily cross-platform as possible. I would strongly >> recommend going down the Mono path here. >> Johnnie >> >>>>> James Bellinger via Mono-devel-list <mono-devel-list@lists.dot.net> >>>>> 11/30/16 11:15 AM >>> >> Well, *they* could switch. My own platform specific libraries do >> detection. Anything else just ends up with lots of vaguely shareable, >> similar, but unshared code. In practice what it means is a developer is >> going to forget to package anything but the Windows version. That may be >> the idea. Making the library *just work*, without the developer having >> to worry about platforms, is best. >> >> I have two libraries I maintain that support both .NET Framework and >> .NET Micro Framework (and Arduino -- libraries for embedded devices), >> and due to how Microsoft ended up putting things in different >> assemblies, even the same classes, it's a cluttered #ifdef mess. Some >> are missing this overload or that. I have to have separate solution >> files. In the future I'll probably just ditch Micro Framework support. >> It's terrible, a hassle to maintain, and even more of a hassle to >> support, debug and test. >> >> It's probably better to pull Microsoft out of the mud as best as >> possible instead of sinking with them. >> >> James >> >> >> On 11/29/2016 10:56 PM, Miguel de Icaza wrote: >>> Hello Jerod, >>> >>> >>> Question as a followup: >>> >>> "This means that some of the work that we will have to do will >>> involve either adjusting the CoreFX code to work in the way that >>> Mono works, or give up on our tradition of having the same >>> assemblies work across all platforms" >>> >>> Is there a preference/leaning one way or another on that point >>> yet, or is it still being investigated? >>> >>> >>> We will have to explore this when we get there. >>> >>> My personal preference is to use the Mono model, but the maintainers >>> of CoreFX likely have their own personal preference to keep their >>> model and they own that code, so we might have to either get creative >>> with the solution that glues CoreFX code in Mono, or adjust Mono. >>> Neither is easy :-) >>> >>> Miguel. >>> >>> >>> _______________________________________________ >>> Mono-devel-list mailing list >>> Mono-devel-list@lists.dot.net >>> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.dot.net%2Fmailman%2Flistinfo%2Fmono-devel-list&data=02%7C01%7Calkpli%40microsoft.com%7C13398987cbd541b00ed008d419673401%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636161378449605412&sdata=a%2BFidT1BzctHoO5k7j852mCJvogSbEvM0mpUYaRb%2FGs%3D&reserved=0 >> >> >> _______________________________________________ >> Mono-devel-list mailing list >> Mono-devel-list@lists.dot.net >> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.dot.net%2Fmailman%2Flistinfo%2Fmono-devel-list&data=02%7C01%7Calkpli%40microsoft.com%7C13398987cbd541b00ed008d419673401%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636161378449605412&sdata=a%2BFidT1BzctHoO5k7j852mCJvogSbEvM0mpUYaRb%2FGs%3D&reserved=0 > > > > _______________________________________________ > Mono-devel-list mailing list > Mono-devel-list@lists.dot.net > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.dot.net%2Fmailman%2Flistinfo%2Fmono-devel-list&data=02%7C01%7Calkpli%40microsoft.com%7C13398987cbd541b00ed008d419673401%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636161378449605412&sdata=a%2BFidT1BzctHoO5k7j852mCJvogSbEvM0mpUYaRb%2FGs%3D&reserved=0 _______________________________________________ Mono-devel-list mailing list Mono-devel-list@lists.dot.net http://lists.dot.net/mailman/listinfo/mono-devel-list