WineHQ to take over Mono

[Posted August 27, 2024 by corbet]

The Mono project was started in 2001 to develop a .NET environment for Linux systems. Microsoft has owned that project since 2016, but has not made a major release since 2019. The company has now announced that Mono is being handed over to the WineHQ organization, which will maintain the repository going forward. Microsoft, meanwhile, is steering users toward its "modern fork" that it continues to maintain.

Huh?

Posted Aug 28, 2024 2:24 UTC (Wed) by magfr (subscriber, #16052) [Link] (8 responses)

So, Microsoft is handing over the mono project to WineHQ but does on the same time recommend that people don't use what they handed over but rather this other thing.

What is the difference between mono and that other thing?

Huh?

Posted Aug 28, 2024 3:10 UTC (Wed) by interalia (subscriber, #26615) [Link]

Yes that was puzzling as well. From the linked Mono website, the front page refers to Microsoft's modern reimplementation dotnet on Github[1]. Doing a bit more searching, according to a Phoronix comment thread[2], Wine uses Mono so it can support legacy .NET apps, so that people don't have to download and install that modern implementation. It may also lack deprecated APIs such as Windows Forms (for GUI apps), so wouldn't support all legacy apps anyway.

[1] https://github.com/dotnet/runtime/tree/main/src/mono
[2] https://www.phoronix.com/forums/forum/phoronix/latest-pho...

Huh?

Posted Aug 28, 2024 7:09 UTC (Wed) by epa (subscriber, #39769) [Link] (5 responses)

Microsoft .NET Framework was for Windows only. Mono was created as a compatible reimplementation of the virtual machine and core libraries to run on Linux (and be free software). Later Microsoft made .NET Core, a new implementation which is cross-platform (and available under a free licence). So Mono is not really needed for new projects. There are some differences in practice between the old .NET Framework/Mono environment and the new .NET Core one, so some older software still needs the older setup.

Huh?

Posted Aug 28, 2024 7:56 UTC (Wed) by taladar (subscriber, #68407) [Link] (2 responses)

It should be noted that .NET Core has some very strange design decisions that are outdated (or never made sense) too, e.g. the fact that the built-in tools prefer older versions that match the constraints to newer ones, making security updates for dependencies hard to install.

Huh?

Posted Aug 28, 2024 18:24 UTC (Wed) by iainn (guest, #64312) [Link] (1 responses)

Yeah, that's a frustrating design flaw. All so they could avoid, at the time, implementing lock files.

Huh?

Posted Aug 28, 2024 18:44 UTC (Wed) by rvdginste (subscriber, #160254) [Link]

I just want to note that nowadays nuget does support package lock files, and you can use "*" as a wildcard in the version of your dependencies. A "force-evaluate" of the dependencies will then upgrade your dependencies.

Yes, the names are confusing

Posted Aug 28, 2024 8:18 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (1 responses)

The support situation is also notable. .NET Core, now just called ".NET" is getting new versions with a set cadence, the way you get new versions of something like Fedora. There's a release every year or so which adds and improves features, half of them expire after 18 months, the others after three years, so you're on a constant treadmill to upgrade the .NET apps in a business, refreshing them every few years. Later this year .NET 9 will ship which most customers won't really use except in toy projects, then in 2025 .NET 10 with three years will get more usage.

But, .NET Framework 4 on the one hand doesn't get these frequent feature bumps, but then also doesn't have a fixed lifetime, .NET Framework 4.8.1 is still supported, code people wrote maybe 5-10 years ago, with mostly bug fixes and small tweaks.

I think it's entirely possible that Microsoft abandons .NET ("core") altogether at some point, but .NET Framework remains supported for years after that. The support for .NET Framework resembles the "Old" Microsoft, the one which made their new Windows NT in the 1990s use APIs which were often inconsistent and confusing because that maximized compatibility with Windows 3.x software, rather than the newer Microsoft which is always in a hurry to tell you that a product has lifetime expired and so that's why a week after your organisation settled on that software it no longer works.

Yes, the names are confusing

Posted Sep 2, 2024 3:41 UTC (Mon) by jmalcolm (subscriber, #8876) [Link]

It is highly unlikely that Microsoft is abandoning .NET and even less likely that they go back to .NET Framework.

The cash cow for Microsoft these days is Azure and the cloud. It is more important than Windows. So, .NET needs to be cross-platform at least on the server side. It needs to run in containers--in Docker and Kubernetes. Framework 4.x does none of that. The active releases of .NET ( versions 6+ ) are what matter to Microsoft.

Microsoft has continued Mono dev within .NET and they are not turning that over to anybody. The fact that they are punting "The Mono Project" to Wine, which is still defined as as clone of Framework, should tell you all you need to know.

Microsoft does not care about .NET Framework ( stuck on 4.x for years as you say ) and they care even less for the Open Source implementation of it ( The Mono Project ).

Huh?

Posted Aug 28, 2024 16:16 UTC (Wed) by thoughtpolice (subscriber, #87455) [Link]

There is the original Mono project that is stewarded by Microsoft, since Xamarin was acquired. There is a fork used by Wine. And there is a fork used by Microsoft specifically as part of the .NET Core project.

The Wine fork is used for their efforts to provide app compatibility, obviously. Microsoft is now giving the original project (acquired via Xamarin) over to WineHQ, so to the extent there are any differences here, they will probably evaporate over time, and WineHQ will be the stewards of Mono going forward.

Microsoft also maintains a fork of Mono that is part of the .NET Core project. .NET Core is its own implementation, though, so why? Well, this fork has differences, but its primary goal is to provide .NET support in some remaining limited places that they require, that aren't supported by CoreCLR (the name for the .NET Core Runtime). For example, this fork of Mono is the basis of "Blazor" which allows you to compile C# to WASM. They also use this fork for some Android/iOS support. This fork of Mono is useful for some platform bringup, non-first-class ports, etc. There is effort within Microsoft to transition these platforms to use CoreCLR, so they will be ported to WASM/iOS/Android, etc. So, eventually, the Mono fork by Microsoft will probably eventually be laid to rest as well.

So, Microsoft is just recommending that if people are trying to use Mono for .NET-Core related stuff, i.e. as an alternative to CoreCLR, then those people should continue to use the fork they provide instead of upstream Mono.

This handoff is otherwise just giving the original project over to a group who will care for it more and will ultimately reduce fragmentation.

Microsoft is turning over "The Mono Project" but not really Mono

Posted Aug 29, 2024 19:38 UTC (Thu) by jmalcolm (subscriber, #8876) [Link]

The other comments here have it right but I will add some emphasis that I see as important.

When Microsoft bought Xamarin in 2016, they bought the Mono dev team. This is the group that created Mono at Ximian, continued it at Novell, and founded Xamarin to create commercial products around it. Up until the Microsoft acquisition, all Mono dev was done within "The Mono Project" and the mono/mono repo on GitHub was where all that happened. While Mono is still in active dev by Microsoft and still seeing new releases, "The Mono Project" has had almost no new development since 2016 with the last release in 2019. "The Mono Project" is not where new Mono dev has been happening.

After Microsoft bought Xamarin, they moved all the Mono dev into their own repositories as a subset of the .NET project ( the real one by Microsoft ). In .NET today, there are two execution environments ( runtimes ) and one of them is Mono ( the other being CoreCLR ). Mono is the runtime that you use if you target a mobile platform with .NET ( like iOS or Android ). So, Mono lives on and is actively developed within the Microsoft tree. This is all cross-platform and Open Source which is awesome. Microsoft occasionally references the Mono runtime by name but mostly it is now just an internal component of .NET ( currently on version 8 with previews of 9 available ).

Around the same time that Microsoft bought Xamarin, they introduced a new .NET implementation. It was originally called .NET Core and there were releases 1.0 through 3.1 with that name. The original version of .NET that had been around since 2001 was then rebranded as ".NET Full Framework".

Since version 5 of .NET, Microsoft has abandoned .NET Framework and the name .NET Core. .NET 6, 7, 8, and now 9 are all ".NET Core + Mono" but the name is just ".NET". There has not been a .NET Core since 3.1. There has not been a new release of .NET Full Framework since verison 4.x, and there has not been a new stable release from "The Mono Project" since 2019.

All .NET dev and all Mono dev has moved into .NET proper ( versions 5 and above ). Both .NET Framework and Mono ( the project to re-implement .NET Framework as Open Source ) are essentially abandoned. .NET Framework ships with Windows and is fully supported by Microsoft but they are not advancing it as a platform. It is legacy. So is "The Mono Project".

All that is to say that, in my view, Microsoft is not at all turning over Mono to anybody. They are keeping it for themselves as part of their active .NET platform. What they are turning over is "The Mono Project" which which they ( including the original Mono dev team ) abandoned long ago along with the .NET Framework Mono was originally meant to mirror.

When The Mono Project was founded, the founders were very clear that their objective was a more productive framework for building cross-platform web and desktop applications ( most notably Linux at the time ). It was copying the design of .NET from Microsoft but was not just a compatibility tool but an actual dev target that people would build applications for. Indeed, the original Mono folks built quite a few desktop applications for Linux early on.

Mono by The Mono Project ceased to be a meaningful target for application development around when Microsoft acquired Xamarin, moved all development out of the Mono Project, and shifted their own focus from .NET Framework to .NET Core ( now just .NET ). If you want a cross-platform framework for application development now, you should just be using .NET itself ( the one from Microsoft -- including the Mono runtime that lurks within it ).

The only real use for Mono as it still exists in the repos of The Mono Project at this point is to target legacy software that was written for the original .NET Framework. Such software was not written to be cross-platform. It was written to be Windows only. In that context, The Mono Project is a great fit for Wine.

There may still be some software out there relied on Mono to provide cross-platform capabilities and that still relies on The Mono Project releases today. I would think that most such software would have moved on to .NET proper by now but who knows. There were also people that built Mono into their own tooling such as the Unity game engine. Again, I think they are mostly moving off to .NET now ( or moving to something else entirely ).