> Mono has no reason to live anymore

This isn't really true. Mono functions as a complete replacement for the ".NET Framework" - something that can be used to run any .NET app, including "legacy" apps targeting old ".NET Framework" versions, on any supported platform, even when the app was built to target Windows.

dotnet/runtime is intended to run more modern applications that target target ".NET Core" - basically, stuff that's cross-platform on purpose.

There are tons of subtle differences relating to these goals but also some glaringly obvious ones, like mono having an implementation of Windows.Forms.

> hence the lack of commits and contributions

Microsoft have been actively forcing contributors out of mono/mono and into the dotnet/runtime repo for several years now, while Wine kept a weird halfway fork at https://gitlab.winehq.org/wine-mono/mono . Formally transferring `mono/mono` and the Mono name over to Wine will in theory allow `mono` to more effectively accept code which works to improve legacy .NET Framework support for compatibility reasons, while dotnet/runtime can continue to evolve as the way to run intentionally targeted .NET Core code.

Won't most apps use way more .net stuff than core? Mono was a way to run dotnet apps on Linux, killing it meant killing cross platform support for modern dotnet desktop apps?

Not really. Best to think of .net “core” as just .net.

Anything that was in the old .net that isn’t in core today won’t ever be.

Then there’s stuff that was missing in the earlier versions of core that existed in old dotnet. Some of it they later realised was useful for newer apps or apps migrated to core. These pieces were ported over by Microsoft or replaced by 3rd party implementations (e.g. avalonia for xplat ui).

(.net core is actually officially just .net, they dropped the core from the name)

Thanks, now it make sense why they dropped the "core" in the name its confusing I thought that meant only the fundamentals

This is Hackernews.

What are those Desktop apps you speak of?

Clearly, everything is a command-line backend pipeline in container with a web UI.

And everything that isn't can be easily deprecated. /s

I know little of dotnet beyond trying various semirandom things to make some .net apps work on linux. With that out of the way, my understanding is that

- Originally there was .Net Framework, by microsoft, for windows only. Versions 1.0 -> 4.8 were released.

- Then mono came along as a somewhat clean-room reimplementation of .Net framework, focusing on making it run on Linux. Though mono does not implement windows gui widgets, so for that there's stuff like Gtk#. And you cannot run windows GUI applications on mono for this reason, even though the core parts might be portable. Eventually Microsoft acquihired the Mono team.

- Later on Microsoft made the core of .net open source and portable, creating .Net Core. Or .Net Runtime, linked above, which is apparently the same thing (not sure when they dropped the "Core" part of the name). Applications written for .Net Framework can't just be recompiled for .Net Core/Runtime, there is porting work that needs to be done. And similarly as for .Net framework, even though the core is portable and open source, the windows gui libraries are not. So again windows GUI applications written using .Net Runtime cannot run on Linux. Not sure if there exists anything like Gtk# for .Net Runtime, allowing creating native Linux GUI applications with .Net Runtime?

- Finally, we have wine which is an implementation of the Windows API on Linux. And in a wine environment you can install e.g. .Net Framework including GUI libraries, so you can run .Net GUI applications that way.

They dropped the "Core" suffix with v5 in 2020, since at that point there was no longer naming confusion.

While Microsoft doesn't have their own framework supporting Linux GUI apps on the modern .NET runtime (MAUI does Mac/iOS/Android but not Linux), there are third-party ones like Avalonia.

Dropping the "Core" suffix introduced more naming confusion. Before that, ".NET" was often used as a shorthand for the (now legacy) .NET Framework. Which makes googling for Core-specific things much harder than it needs to be.

> not sure when they dropped the "Core" part of the name

It was called .NET Core until they officially retired the .NET Framework (ie v4) by releasing .NET 5.

See https://news.ycombinator.com/item?id=41372165

It is harmful to write new code that targets .NET Framework and existing actively maintained applications all have migrated to .NET. The ones that did not either have poor maintenance or authors that lack time as they don't owe extra effort unless they want to do that (or sometimes it is a skill issue, unfortunately).

Mono has support for app domains (and is in general closer to .NET Framework), a more powerful C API and runs on more architectures.

This must be the reason. Wine seeks to be compatible with a bunch of legacy software, some of which will want to use the equivalent of .NET 1, 2, 3, and 4.x Framework and not just "dotnet core". (Or whatever the new thing is called in Microsoftese this week.)

Edit: maybe this means WPF can be the best way to write Linux applications. After all, Win32 is the stable Linux API... nudge nudge, wink wink. :-D

So if I am understand correctly, what I mentioned is correct?

On the website (where my quote comes from) it links to https://github.com/dotnet/runtime/tree/main/src/mono which is a mono within what you linked too.

So this is a case of 2 different mono's?

Sorry just trying to make sure I am understanding what is happening here properly given the exact same name in 2 places...

Winehq is probably the only org who might have needs to add something in there. So why not have a control of it, even if the contributions are rare.

Edit: To add, isn’t the above about ASP .NET Core? Mono is mostly about the time before Core, and it is not the same.

> Mono has no reason to live anymore

More targets, much leaner (< 10 MB clr + mscorlib), less than factor two performance difference to current CoreCLR, written in C, easier to compile than CoreCLR, etc.