[Mono-dev] Future of Mono's .NET Code Sharing
Miguel de Icaza
miguel at microsoft.com
Thu Dec 1 14:42:30 UTC 2016
That would still work Johnnie, it would just be a Mono implementation detail that matters to people porting Mono to new platforms or actively involved in working in the core of Mono.
On 11/30/16, 3:37 PM, "Mono-devel-list on behalf of Johnnie Odom" <mono-devel-list-bounces at lists.dot.net on behalf of jodom at escambia.k12.fl.us> 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.
>>> 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.
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 :-)
> Mono-devel-list mailing list
> Mono-devel-list at lists.dot.net
Mono-devel-list mailing list
Mono-devel-list at lists.dot.net
More information about the Mono-devel-list