[Mono-dev] Future of Mono's .NET Code Sharing

Wed Nov 30 22:03:42 UTC 2016

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 <eb1 at 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 at 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 at 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 at 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 at 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