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

[Eberhard Beilharz]

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
>> http://lists.dot.net/mailman/listinfo/mono-devel-list
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.dot.net
> http://lists.dot.net/mailman/listinfo/mono-devel-list