Microsoft donates the Mono Project to the Wine team

Mono was, but newer versions of .NET run on Linux and Mac.

You can install at the link below, and then making a project is just `dotnet new console` and run with `dotnet run`

https://learn.microsoft.com/en-us/dotnet/core/install/linux

For modern .NET, you don't need to know anything about the legacy terms of Mono, .NET Core, .NET Framework, .NET Standard, etc. All you need is .NET 8 SDK. It's fully-cross platform and installs support for both C# and F#.

For example, just download .NET 8 SDK on whatever platform, which is usually very easy on most platforms, and then run `dotnet fsi` to get into an F# REPL.

You’re not alone.

I would say I’m not ‘new’ and even developed .net 4.5 for a number of years. I’m just as stumped by the naming mess that Microsoft made across the board in that space.

Edit: I say 4.5 because I mean the original thick .net which is not dotnet core, which I think is the way to differentiate between versions, but also all the sub libraries like the orm were iirc named the same but did different things.

They should have rebadged everything with a new name that didn’t involve a word that is fairly painful to google (‘core’) can be used in development as well as the name of a framework.

As the OP notes, MS use their own fork of Mono for the .NET Core runtime these days. So you're not wrong but they are different codebases these days.

dot.net is the official starting point. It'll point you to getting setup with .NET dev on Linux. You can either use VSCode or Intellij Rider.

This is the official one: https://learn.microsoft.com/en-us/shows/visual-studio-code/g...

If you just want to get into .NET (C# or F#) on non-Windows platforms, the latest .NET release (at the time of writing, 8.0) is what you want. The development experience is good these days.

For a historic summary of why it used to be a confusing situation (up until maybe 2020), see https://two-wrongs.com/dotnet-on-non-windows-platforms-brief...

That also has some background on why the Mono project found itself in a weird spot.

Is there somewhere where someone new to the ecosystem can get a simple introduction to all of these different terms and which ones are still relevant today?

Not really. It's legacy cruft all the way down.

But the good news is that if you stay on the beaten path, using the latest SDK and targeting the latest Runtime, everything Just WorksTM.

I looked into .NET somewhat recently and came away with the apparently mistaken impression that Mono was how .NET did cross-platform. I guess I must have been reading old docs,

History here https://en.wikipedia.org/wiki/.NET

.NET Core 1.0 (2016) was the first cross platform prototype. It got good in a release in 2018 or 2019, I even forgot which now. And took over steadily after that.

We don't even think about it any more. "which OS is the prod env on" isn't a factor that causes any support worries at all.

Getting set up would start at https://dot.net/

And the download page, which should show you content for your current OS https://dotnet.microsoft.com/en-us/download

But also other targets are here https://dotnet.microsoft.com/en-us/download/dotnet/8.0

You'll want the latest SDK 8.0.x

Aside from following the default 'start here' documentation, there are various timelines made for fun and profit that visualize the full history, for example:

https://time.graphics/line/291016

This is quite overwhelming, but it can still be useful when reading an article about .NET that is either older or refers to history as you can quickly see where in time it is located.

.NET Core is available for Debian, you just have to add Microsoft's APT source [1].

Fedora [2], Ubuntu [3], and FreeBSD [4] build .NET from source themselves. A lot of work has been done to make it possible to build .NET from source [5] without closed source components, so it might just be a matter of someone being motivated to create the package for Debian.

[1]: https://learn.microsoft.com/en-us/dotnet/core/install/linux-...

[2]: https://src.fedoraproject.org/rpms/dotnet8.0

[3]: https://launchpad.net/ubuntu/+source/dotnet8

[4]: https://github.com/freebsd/freebsd-ports/tree/main/lang/dotn...

[5]: https://github.com/dotnet/source-build

You can add add Microsoft's repo to install it on Debian: https://learn.microsoft.com/en-us/dotnet/core/install/linux-....

Does Debian require packages to work on all of its architectures? If so, that could be the issue. .NET Core only supports x86, x64, and Arm64 (I think Arm32 has been discontinued and RISC-V is experimental at this point).

It's possible that they object to .NET Core having certain license restrictions on the Windows port (https://github.com/dotnet/core/blob/main/license-information...). .NET Core is mostly MIT or Apache licensed, but the Windows SDK has some additional terms. Skimming the third party licenses, that doesn't seem like an issue (mostly MIT/BSD/Apache or similar).

I think the licensing situation is an interesting question: if you have software that's 100% open source when compiled for your OS, but requires non-free stuff to run on Windows, is it ok to include in Debian? It looks like none of the non-free stuff (like WPF) gets distributed with the non-Windows SDK builds. Binaries created from your code only depend on MIT-licensed stuff on macOS and Linux, but might depend on something closed-source when targeting Windows - though it looks like almost all of that stuff is either WPF (so you wouldn't be able to develop on Linux/Mac anyway since those libraries wouldn't be in the SDK on those platforms) or were removed as a runtime dependency in .NET 7. It looks like `Microsoft.DiaSymReader.Native` might be the only thing left. Maybe that's what is holding it back?

also, does dotnet-core have a reasonable aot story for things like esp32 and ch32v003?

"Reasonable" can be a lot of things to a lot of different people. People have been working on RISC-V support. Samsung seems interested in it. But I probably wouldn't recommend it at the moment - and Mono doesn't really have RISC-V support either.

Even with AOT compilation, as someone who loves C# and also does embedded development in C I would personally say a garbage collected language like C# has no place there.

I believe that you would use dotnet nano for something like that. I used it (or some previous version of it) once many years ago and was very impressed with the productivity and ease of use it offered. Ultimately the lack of community surrounding it drove me to other technologies. Might have changed since then though, who knows!

https://www.nanoframework.net/

Microsoft as a company is extremely myopic. Budgets are scrutinized down to the penny every few months at very senior levels. This drives a culture of immediacy. Wine was a threat until Microsoft realized everyone in tech had moved to service based business models (aka "cloud"). Only afterwards, did they "realize" Linux as a threat to their long term viability no longer mattered.

Wine/Proton helps make the Win32 and DirectX APIs a sort of de-facto cross-platform standar

There are perfectly fine _actual_ cross-platform standards like Vulcan and OpenGL. If your goal is cross-platform, making a Windows app that you hope will be converted well enough is a strange way to approach it.

that Wine/Proton helps make the Win32 and DirectX APIs a sort of de-facto cross-platform standard when it comes to things like desktop gaming, and that this is a good thing for them.

I'm not sure if it benefits microsoft in the long term, because the "backwards compatibility" features of Wine need to be implemented in Windows already as a part of the system. So in the long run wine/proton/mono will implement windows features on linux in an optional/replaceable/modular way in user-space while keeping backwards compatibility for older windows software, while windows is forced to implement (and distribute these features) with their OS and has to sacrifice backwards compatibility if they want to simply their OS.

I would say that the adoption of wine/proton helps the linux ecosystem a lot more because there wasn't a standard executable format for linux beforehand (static? tarball of program and dynamic libraries? .deb file? AppImage? Flatpak? Higher-level language like java?). How do you reliably link to libraries like mesa or even glibc? Now there is a solution: just distribute a windows program and test it to confirm it works in wine/proton. Perhaps it is better for DirectX adoption, but it seems like Vulkan/OpenGL/WebGPU are still superior in terms of cross-compatibility, regardless if you use wine or not.

I disagree. MS was completely succesfull in their goals. They kept a ton of developers busy learing useless Xamarin, thus keeping them from developing products that can actually compete with Microsoft products.

Next they killed of an open source competitor (Mono) of their product, stole the usefull bits to put it in .Net, and now they dump the leftover project (that's not competing with them anymore) back into the OS world.

How is that not a smart way of doing business?

I think it's just such a clear business-razor because of the cloud: can I take my app and spin up a bajillion cheapo servers with no licensing costs using that stack?

If the answer for .Net was 'no' then there are meaningful domains where people would just jump ship in a second. Research, academia, teaching, and certain government areas pop to mind. Keeping Linux support, because of that server dominance, is a core concern for them.

If MS was smart, they would try to get the devs working on Xbox projects to use their coding platforms for other type of development.

anthropomorphizing complex social institutions such as corporations is ultimately unproductive and a net negative for clear thinking

I still don't trust MS's motives in general

I think it's the same for any global enterprise: profit.

In that regard, "trusting" something like MS is like evaluating their stock: what do they make money off, what is a threat to that. Which makes it rather easy to "trust" them: if they can make money off SomeOpenSourceProject they'll help it along, if it doesn't help, nor threat, they'll ignore it. If it's a threat, they'll put (some) money towards fighting it.

For me the difficult part, and why I still don't fully trust MS, even with Github or VScode lies in their internal competition: MS has projects that directly compete eachother. Business-wise it makes no sense to me (and is the primary reason I'll stay away from investing in MSFT). But also their internal competion between profit now and delayed profit. MS has often done things (or not done things) that increase the bottom line this quarter, but harm them over years. In that regard too, MS makes no sense to me Business-wise. I guess having a cash-cow-"monopoly" for decades kinda absolves them of the responsibility to run the entire company in a way that makes sense business-wise.

Maybe they feel the same about Wine as I do about WSL.

You can argue that the my-thing-wrapped-inside-your-thing increases exposure to my-thing and that's a net good outweighing any other factors, but you can just as validly argue it helps divert from actual adoption of my-thing and facilitates never moving from your-thing, since no one has any actual empirical study, it's all just feelings and beliefs.

Maybe one logical argument that might have some meat is maybe WSL/Wine just means that the exposure vs crutch aspects cancel each other out (for every user who is exposed to foreign-thing and maybe decides to adopt it, there is another user who thanks to the swallowed version does not ever have to to move), and if that's true, then any imbalance in effects comes down to the the innate virtues of the two things. Both groups of people are equally exposed to both platforms and have equally good-enough use of both platforms, and neither has to actually change to get the benefits of the other, and so the user will choose whichever actually seems to serve their needs the best as their native platform.

I wonder if it's possible to make a desktop backed by WSL that would be a better experience than the current ad/spying-riddled Windows native desktop? Then MS would be forced to try to enshittify WSL so that it doesn't provide an escape and superior experience from the current Windows experience. Is WSL a good thing THEN?

At least for now, WSL has absolute crap access to hardware, not even just like gpus for gaming but even simple things like access to a usb-serial adapter. So, it's probably not possible to make a functional WSL desktop yet. Maybe such things will intentionally never be fixed in WSL just for this reason, so you can only ever use it for pure web app development no different from a cloud instance.

.Net SRE here, all our .Net REST APIs are deployed on Kubernetes. Devs are still mostly on Windows because Visual Studio.

I've worked with Azure team, all greenfield they do for Azure goes on Linux as well. Windows Server is pretty much dead to Microsoft though it will be continue to be supported and released because $$$.

Few work on Macbooks, it is more about using WSL on the dev machines or even using DevBox instances.

Our .NET teams are increasingly choosing MacBooks with Jetbrains Rider.

I imagine very few of the MS devs are using BeOS.

Microsoft’s EULA would still apply to (b).

It’s the exact same situation as downloading a Windows ISO from Microsoft’s website and running it with an activator.

You are not alone. It’s not a well defined problem, hence lawsuits. API is also such a broad term, it’s hard to establish borders.

What tool is that?

I'm not a dog person: a puppy would be a burden (financially and time-wise) and provide me barely any fun.

Please tell me there is a separate French word for free (as in puppies).

Because nobody wanted to maintain it.

I guess this is in the context of "free as in beer" and "free as in speech".

White elephant has usually been the go to animal for this kind of idiom

I love this. Definitely using this next time someone tries to guilt me into becoming maintainer of some abandonware foss project.

Winforms and WPF are both very maintained and supported for .NET 8 on Windows, to clarify. Good cross platform desktop frameworks include Avalonia.

Mono also supports winforms. I don't think they're supported in dotnet (but there's libraries for Gtk, although you could also use Vala with a bit extra effort).

A shoutout goes to a project that aims to simplify CoreCLR embedding UX to prevent the issues stemming from embedding legacy Mono: https://github.com/StudioCherno/Coral

For a beginner, high school but zero experience in programming, which one easier to learn, C# or F#?

I last touched LINQ in college in 2016 - isn't it basically an ORM for C#? Not super unique but I assume very relevant to use when working with C#.

If with C# you can create a fully static binary which runs on an empty scratch docker, I will properly consider your opinion. Until then: Go à gogo!

Is AOT compiling your binaries [1] an option for you? The starting size of AOT compiled C# can beat Go in size [2] and from there it really depends on what you do and how you do it. Some simple ASP.NET server with https and routing can comfortably fit under 10 MB and there are compilation options that can help optimize further [3].

[1] https://learn.microsoft.com/dotnet/core/deploying/native-aot... [2] https://github.com/MichalStrehovsky/sizegame?tab=readme-ov-f... [3] https://learn.microsoft.com/dotnet/core/deploying/native-aot...

Do your civic duty and disable telemetry everywhere you go. :)

export DOTNET_CLI_TELEMETRY_OPTOUT=1

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.

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 ".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.

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

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.

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...

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.

OK, but that doesn't require any further changes to Mono. It should essentially be a read-only project going forward.

So Microsoft gave the Wine project the software equivalent of a stained mattress?

So ...throwing it over the fence into the neighbor's yard, then?

This is not an accurate assessment, I'm afraid.

The comparison we discussed was for unrepresentative code that used none of the features that make .NET fast (generics, SIMD, expected forms of inheritance and abstraction and devirtualization they enable, CoreLib APIs). The closest case in there was JSON serialization which CoreCLR was 385% faster at. It is unfortunate that you feel a need to say this, knowing that it doesn't even show a tip of the iceberg.

Please do not mislead casual readers here with such comments.

They will have a bad time running basic programs - the original Mono is outdated and cannot execute assemblies that target non-legacy versions, and the Mono that lives in dotnet/runtime (which you have to go out of your way to use on CoreCLR platforms) tends to have all kinds of regressions on user-provided code that is not as robust on runtime checks to ensure that Mono does not accidentally go onto the path that that it has especially bad regression on. Even CoreLib code nowadays uses more and more struct generics assuming monomorhpization which performs poorly on Mono. There is very little work done to improve performance on Mono with effort invested mostly in WASM area and to ensure it does not regress further. Major platforms like Android and iOS are in the slow but steady progress to migrate to CoreCLR/NativeAOT (there are other reasons not in the least much smaller binary size). And for WASM there is NativeAOT-LLVM experiment that is likely to make Mono obsolete for that target too.

The workloads that matter and are representative are the ones produced by C#, F# and VB.NET compilers as well as projects that care about exercising the standard library and/or produce recommended CIL forms (like https://github.com/FractalFir/rustc_codegen_clr).

If we compare the last major release of Mono back in 2019, where there was a real improvement to the CLR (not just bug and security fixes), with the CoreCLR versions at that time, the factor is rather 1.1 (see e.g. https://www.quora.com/Is-the-Mono-CLR-really-slower-than-Cor...).

Ever heard of Rotor?

https://www.codeguru.com/dotnet/net-nuts-bolts-the-joy-of-ro...

Or DotGNU?

https://www.gnu.org/software/dotgnu/

What happened to Xamarin looks like Microsoft took whatever IP was relevant, and left everything else go, which this decision is a confirmation thereof.

It is kind of interesting to see Miguel's feedback, now that he his allowed to talk about how things went down.

A value you come up with hoping the IRS will not one day disagree.

And Wine will probably not do much more than maintenance so applications targeting .net 1-4 work on Wine.

And Godot!

Always nice to see that SL is still going. I'll probably never remember my login to my old 2006 era account but the years of weird virtual world memories remain.

Thank you!

So it ran on Windows, FreeBSD and Mac OS X making it the first non-Windows implementation of .Net, but it didn't run on Linux. It also had a fairly useless licence, so Mono was separate.

https://en.wikipedia.org/wiki/Shared_Source_Common_Language_...

Edited to add: and thanks for the link. Only three developers and there's already drama! :-)

Well, let's say they wanted to use Linux, but run their windows software on it.

thanks!

I kept thinking Microsoft needs to port a windows version for their handheld, doesn't want to use steamos, but also needs to work with 'interesting' hardware. Their answer would be a linux port imo, but having too much there could annoy trust regulators so they divested from mono. but I had zero proof for any of these hunches.

Wine is becoming like archive.org, but for win32 runtimes.