-
For everyone who is confused by what is going on, here's the explanation:
Today, there are 2.5 Mono's:
Mono that lives in https://github.com/mono/mono. This is the original Mono codebase that was written back then and was the .NET Framework for Linux, with corresponding compat. and such, pioneered by Miguel De Icana, who now seems to be happier in Swift land. At the present day, it was receiving very little maintenance and I don't believe was actively used. Please correct me if I'm wrong.
Mono that lives in https://github.com/dotnet/runtime/tree/main/src/mono. This is the mono that got "merged" into .NET, giving the basis for multiple components and becoming one of the official runtime flavours. It is actively maintained and is at relative feature parity with CoreCLR, predominantly serving mobile targets (iOS, Android) and WASM as well as exotic or legacy targets like ARMv6, LA64, s390x(?), ppc64. Note that you are not expected to use it for targets that support CoreCLR due to absolutely massive rift in performance between the two. When you are using it, you do so as a part of standard .NET toolchain - it is picked automatically for appropriate targets, or can be opted into with some configuration.
Mono that lives in https://gitlab.winehq.org/wine-mono/mono which is a Mono fork actively maintained by Wine for its own usage. Going forward, any possible ambiguities regarding ownership and stewardship are considered resolved and the ownership of mono/mono and everything related to it is transferred to WineHQ.
Honorable mention also goes to private Mono fork used by Unity which they are (painfully) trying to migrate from.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
For everyone who is confused by what is going on, here's the explanation:
Today, there are 2.5 Mono's:
Mono that lives in https://github.com/mono/mono. This is the original Mono codebase that was written back then and was the .NET Framework for Linux, with corresponding compat. and such, pioneered by Miguel De Icana, who now seems to be happier in Swift land. At the present day, it was receiving very little maintenance and I don't believe was actively used. Please correct me if I'm wrong.
Mono that lives in https://github.com/dotnet/runtime/tree/main/src/mono. This is the mono that got "merged" into .NET, giving the basis for multiple components and becoming one of the official runtime flavours. It is actively maintained and is at relative feature parity with CoreCLR, predominantly serving mobile targets (iOS, Android) and WASM as well as exotic or legacy targets like ARMv6, LA64, s390x(?), ppc64. Note that you are not expected to use it for targets that support CoreCLR due to absolutely massive rift in performance between the two. When you are using it, you do so as a part of standard .NET toolchain - it is picked automatically for appropriate targets, or can be opted into with some configuration.
Mono that lives in https://gitlab.winehq.org/wine-mono/mono which is a Mono fork actively maintained by Wine for its own usage. Going forward, any possible ambiguities regarding ownership and stewardship are considered resolved and the ownership of mono/mono and everything related to it is transferred to WineHQ.
Honorable mention also goes to private Mono fork used by Unity which they are (painfully) trying to migrate from.
-
Uno Platform
Open-source platform for building cross-platform native Mobile, Web, Desktop and Embedded apps quickly. Create rich, C#/XAML, single-codebase apps from any IDE. Hot Reload included! 90m+ NuGet Downloads!!
-
Avalonia
Develop Desktop, Embedded, Mobile and WebAssembly apps with C# and XAML. The most popular .NET UI client technology
> - If you are working on Linux, you can build and deploy Android apps only
> - You need a valid Visual Studio or IntelliCode subscription
You don't: https://marketplace.visualstudio.com/items?itemName=ms-dotne... (DevKit, which is the licensed one, is completely optional - it gives you VS-style solution explorer. You can already get it with e.g. F#'s Ionide that works for any .NET Code file)
Or https://github.com/razzmatazz/csharp-language-server with either Neovim or Emacs.
> Okay, where's Linux? That's what Mono was originally made for and where Mono really shines.
Regretfully, you have ignored all sibling comments, so here it goes:
Uno: https://platform.uno/docs/articles/get-started-vscode.html?t...
(Uno has more involved setup than Avalonia but has way better mobile targeting, and casual reports indicate smaller memory footprint)
Avalonia: https://avaloniaui.net + https://marketplace.visualstudio.com/items?itemName=Avalonia...
dotnet new --install Avalonia.Templates -
source-build
A repository to track efforts to produce a source tarball of the .NET Core SDK and all its components
.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
-
since C# 2 or maybe 1? No setup required. You can echo this snippet into Program.cs and it will work as is.
(I'm not sure if binding process on the ole Mono was any different? In any case, the above is a thing on Linux since 8 years ago at least)
Like with other false claims, the "better native packaging" one is easily disprovable. Just look at the list of supported platforms here: https://github.com/sandrohanea/whisper.net?tab=readme-ov-fil...
It even supports CoreML on iOS and macOS.
* It is a bit ironic that this now applies to C# too but for completely different reason - you can usually replace data crunching C++ code with portable pure C# implementation that retains 95% of original performance while reducing LOC count and complexity. Huge maintenance burden reduction and "it just works" without having to ship extra binaries or require users to pull extra dependencies.
-
Coral
Coral is a C++/C# wrapper around the .NET CoreCLR library, the purpose of Coral is to provide a native interface similar to Mono, but in a more modern style, and using .NET Core instead of .NET Framework (by StudioCherno)
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
-
-
dotnet
Home of .NET's Virtual Monolithic Repository which includes all the code needed to build the .NET SDK from source (by dotnet)
-
.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
-
rustc_codegen_clr
This rust compiler backend(module) emmits valid CIL (.NET IR), enabling you to use Rust in .NET projects.
No, it is not.
The comparison we discussed was for unrepresentative code that used none of the features that make .NET fast (especially generics, SIMD and devirtualization). The closest case in there was JSON serialization. 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).
-
Static fields may be placed on Frozen Object Heap. The values of static readonly fields may not exist at all if the ILC's static constructor interpreter can pre-initialize it at compile-time and bake the value into binary or codegen. DynamicPGO does a similar optimization but for all cases, relying on recompilation. This is with JIT though which is not usable in such environment.
There is no concept of globals in .NET the way you describe it - you simply access static properties and fields.
In practice, you will not be running .NET on microcontrollers with existing mainline runtime flavours - very different tradeoffs, much like no-std in Rust. As mentioned, there is NanoFramework. Another one is https://www.wildernesslabs.co which my friend is using for an automated lab for his PhD thesis.
Last mention goes to https://github.com/bflattened/bflat which supports a few interesting targets like UEFI. From the same author there's an example of completely runtime-less C# as well: https://github.com/MichalStrehovsky/zerosharp. It remains a usable language because C# has a large subset of C and features for manual memory management so writing code that completely bypasses allocations is very doable, unlike most other GC-based languages.
-
zerosharp
Demo of the potential of C# for systems programming with the .NET native ahead-of-time compilation technology.
Static fields may be placed on Frozen Object Heap. The values of static readonly fields may not exist at all if the ILC's static constructor interpreter can pre-initialize it at compile-time and bake the value into binary or codegen. DynamicPGO does a similar optimization but for all cases, relying on recompilation. This is with JIT though which is not usable in such environment.
There is no concept of globals in .NET the way you describe it - you simply access static properties and fields.
In practice, you will not be running .NET on microcontrollers with existing mainline runtime flavours - very different tradeoffs, much like no-std in Rust. As mentioned, there is NanoFramework. Another one is https://www.wildernesslabs.co which my friend is using for an automated lab for his PhD thesis.
Last mention goes to https://github.com/bflattened/bflat which supports a few interesting targets like UEFI. From the same author there's an example of completely runtime-less C# as well: https://github.com/MichalStrehovsky/zerosharp. It remains a usable language because C# has a large subset of C and features for manual memory management so writing code that completely bypasses allocations is very doable, unlike most other GC-based languages.
-
It does indeed still work that way! We even still support the old, in-house VM, known as LSO2: https://wiki.secondlife.com/wiki/LSO
We're hard at work adding Luau (https://luau.org) as a supported language for both in-world scripting as well as client/viewer-side scripting. As a handy byproduct of that, LSL will also gain the ability to be compiled to Luau bytecode, allowing us to eventually (someday, at least) shed any need for our custom-patched version of Mono 2.6. More juicy details here: https://wiki.secondlife.com/wiki/Lua_FAQ
Source: I work at Linden Lab. If these sorts of things excite anyone, we're hiring!
-
-
sdk
Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI (by dotnet)
I hate to defend telemetry of all things but in this particular case the criticism is unfounded and lacks context:
https://dotnet.microsoft.com/en-us/platform/telemetry
https://learn.microsoft.com/en-us/dotnet/core/tools/telemetr...
https://github.com/dotnet/sdk/tree/main/src/Cli/dotnet/Telem...
In any case, Debian would use https://github.com/dotnet/source-build and dotnet/dotnet, and could easily include the argument or a patch for this. It’s unlikely to be an issue. My bet it was not in Debian because there was no one to take initiative or there was but that person has faced a backlash by people in Debian who are similar to vocal minority here that posts FUD because of their little personal crusade.
-
[2] https://github.com/MichalStrehovsky/sizegame?tab=readme-ov-f...
-
-
> - If you are working on Linux, you can build and deploy Android apps only
> - You need a valid Visual Studio or IntelliCode subscription
You don't: https://marketplace.visualstudio.com/items?itemName=ms-dotne... (DevKit, which is the licensed one, is completely optional - it gives you VS-style solution explorer. You can already get it with e.g. F#'s Ionide that works for any .NET Code file)
Or https://github.com/razzmatazz/csharp-language-server with either Neovim or Emacs.
> Okay, where's Linux? That's what Mono was originally made for and where Mono really shines.
Regretfully, you have ignored all sibling comments, so here it goes:
Uno: https://platform.uno/docs/articles/get-started-vscode.html?t...
(Uno has more involved setup than Avalonia but has way better mobile targeting, and casual reports indicate smaller memory footprint)
Avalonia: https://avaloniaui.net + https://marketplace.visualstudio.com/items?itemName=Avalonia...
dotnet new --install Avalonia.Templates -
Silk.NET
The high-speed OpenGL, OpenCL, OpenAL, OpenXR, GLFW, SDL, Vulkan, Assimp, WebGPU, and DirectX bindings library your mother warned you about.
(can also do F# and Elmish F# with FuncUI!)
Gir.Core (GTK4 and co.): https://gircore.github.io/docs/use.html
ImGui with Silk.NET: https://github.com/dotnet/Silk.NET/blob/main/examples/CSharp...
-
> There is also an exercise in writing JNI bindings. Or maybe using Java FFM now which still requires you to go through separate tooling, build stage, deal with off-heap memory management API and still does not change the performance profile significantly. There's a reason it is recommended to avoid native dependencies in Java and port them instead (even with performance sacrifices).* Green Threads will only exacerbate this problem.
I'm not sure if you've used JNA before? That's been the state of the art for many years: https://github.com/java-native-access/jna
public interface MSVCRT extends Library {
