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? 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, but I'm pretty sure they were at least semi-official.
Is there good documentation somewhere for getting set up to develop with modern .NET on 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.
This is from Mint 22. MS does have its own PPA though.
$ apt search dotnet
p dotnet-apphost-pack-6.0 - Internal - targeting pack for Microsoft.NET
p dotnet-apphost-pack-7.0 - Internal - targeting pack for Microsoft.NET
p dotnet-apphost-pack-8.0 - Internal - targeting pack for Microsoft.NET
p dotnet-host - dotNET host command line
p dotnet-host-7.0 - dotNET host command line
p dotnet-host-8.0 - .NET host command line
p dotnet-hostfxr-6.0 - dotNET host resolver
p dotnet-hostfxr-7.0 - dotNET host resolver
p dotnet-hostfxr-8.0 - .NET host resolver
p dotnet-runtime-6.0 - dotNET runtime
p dotnet-runtime-7.0 - dotNET runtime
p dotnet-runtime-8.0 - .NET runtime
p dotnet-runtime-dbg-8.0 - .NET Runtime debug symbols.
p dotnet-sdk-6.0 - dotNET 6.0 Software Development Kit
p dotnet-sdk-6.0-source-built-arti - Internal package for building dotNet 6.0 So
p dotnet-sdk-7.0 - dotNET 7.0 Software Development Kit
p dotnet-sdk-7.0-source-built-arti - Internal package for building dotNet 7.0 So
p dotnet-sdk-8.0 - .NET 8.0 Software Development Kit
p dotnet-sdk-8.0-source-built-arti - Internal package for building the .NET 8.0
p dotnet-sdk-dbg-8.0 - .NET SDK debug symbols.
p dotnet-targeting-pack-6.0 - Internal - targeting pack for Microsoft.NET
p dotnet-targeting-pack-7.0 - Internal - targeting pack for Microsoft.NET
p dotnet-targeting-pack-8.0 - Internal - targeting pack for Microsoft.NET
p dotnet-templates-6.0 - dotNET 6.0 templates
p dotnet-templates-7.0 - dotNET 7.0 templates
p dotnet-templates-8.0 - .NET 8.0 templates
p dotnet6 - dotNET CLI tools and runtime
p dotnet7 - dotNET CLI tools and runtime
p dotnet8 - .NET CLI tools and runtime
p libgtk-dotnet3.0-cil - GTK.NET library
p libgtk-dotnet3.0-cil-dev - GTK.NET library - development files
dotnet-sdk-8.0 should have the rest of what you need downstream from there. For other libraries and versions, you should be able to use NuGet with your project directly.
I've been using the script installer version intended for ci/cd as I actually like that installer more, it's the only one that really supports multiple versions correctly.
What's unfriendly about just clicking through the options? Anytime I want to install .NET, I just go to that exact documentation, click on the distribution I want (usually Ubuntu), and then just click on the version (https://learn.microsoft.com/en-us/dotnet/core/install/linux-...). I almost always use Microsoft's feeds though, so as to not rely on the middleman of the Ubuntu package manager feeds.
Ubuntu is a subpar package maintainer, but in well run distros that middleman who does the packaging makes an effort to ensure you are getting a stable, performant package, and tries to catch eratta or abusive practices that upstream starts pushing (say, Microsoft opening Edge when you run wget or curl in the terminal, rather than calling the real wget or curl).
To a point. Making cross platform native desktop apps is still in the hands of 3rd party vendors such as Avalonia and Uno. MAUI was supposed to fix that oversight to a less than stellar results.
If there were an old version of C that only worked on one platform but had a graphical toolkit in its standard library, and a new version of C that is cross platform but that graphical toolkit is now ambiguously still sort-of part of the standard library but still not cross platform (and there was no realistic alternative)... Then yes it would be valid to object C is not really cross platform.
back when .NET was first launched it was advertised as the new way of making desktop applications on Windows.
Visual C# made it very easy to design GUI interfaces.
So this "it's all for backend now" notion is surprising.
.Net is "Microsoft Java". Like Java it was designed to do everything, but as desktop development died (and mobile development was locked down by Apple and Google, limiting it to their corporate languages), it pivoted towards networked applications.
They were legally forbidden from going the Embrace-Extend-Extinguish route there, so they had to build their own version from scratch. C# exists because J++ couldn't.
Is Kotlin the most "active", "hot", or "up-and-coming" competitor? Possibly. But the "largest"? Its deployed footprint and popularity are nowhere close to Java's at this point in time.
No and it's not even close. Kotlin only has a single Jetbrains Compose (I presume Kotlin Multiplatform is the same thing). It is also subject to the quirks and specifics of JVM implementations, build-systems and package management. Kotlin native partially bypasses this, but its performance is a factor of 0.1-0.01x vs OpenJDK (if there is new data - please let me know). This is very unlike NativeAOT which is on average within 90% of CoreCLR JIT but is also a performance improvement in variety of scenarios.
C# and F# get to enjoy the integration that is "much closer to the metal" as well as much richer cross-platform GUI frameworks ecosystem with longer history.
There are more than 10 sibling and gp comments that exhaustively address the GUI and other questions :)
> That's a massive advantage over the arcane package management and build systems of .NET.
Very few languages ever achieve a build and package management system as mature and usable as the Java ecosystem.
I've been waiting for 12 years for .NET to match Java's ecosystem, and it's still not there yet.
If you want to sell me on "advantages" of invoking Gradle or Maven over
dotnet new web
dotnet run
curl localhost:port
or
dotnet new console --aot
echo 'Console.WriteLine($"Right now is {DateTime.Now}");' > Program.cs
dotnet publish -o {here goes the executable}
or
dotnet add package {my favourite package}
I suppose you would actually need 12 years of improvements given how slow if ever these things get resolved in Java land.
Also, what's up with Oracle suing companies for using incorrect JDK distribution that happens to come with hidden license strings attached?
Well, that's where the problem lies, isn't it? The ecosystem for .NET is extremely limited compared to what's available for the JVM
And the way JVM packages are distributed, with native libraries, BOMs and platforms allows more versatility than any other platform.
The build system may be better in dotnet, but that only really matters for the first 10 minutes. Afterwards, the other tradeoffs become much more important.
I don't think "JVM is more popular" argument does justice to Java (and Kotlin) strengths. With this reasoning, you could also say "C++ is more popular for systems programming" but it doesn't stop developers from switching to Rust, Zig or even C# as a wider scope and easier to use language that has gotten good at it.
Nonetheless, you could make this argument for select Apache products, but that's Apache for you. It does not hold true for the larger ecosystem and, at the end of the day, quantity is not quality, otherwise we would've all been swept by Node.js :)
Same applies to "packages that bundle native libraries".
First, they are always maintenance-heavy to manage with ever growing matrix of platforms and architectures. Just x86 alone is problem enough as all kinds of codecs perform wildly different depending if AVX2 or 512 is available vs SSE4.2 or even SSE2 without EVEX. Now add ARM64 with and without SVE2 to the mix. Multiply this by 2 or 3 (if you care about macOS or FreeBSD). Multiply linux targets again by musl and glibc. You get the idea. This a worst-case scenario but it's something Java is not going to help you with and will only make your life more difficult due to the reason below.
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.
Meanwhile
using System.Runtime.InteropServices;
[DllImport("libc", EntryPoint = "putchar")]
static extern int PutChar(int c);
var text = "Hello, World!\n";
foreach (var c in text) PutChar(c);
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)
* 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.
> 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.
public interface MSVCRT extends Library {
public static MSVCRT Instance = (MSVCRT) Native.load("msvcrt", MSVCRT.class);
void printf(String format, Object... args);
}
public class HelloWorld {
public static void main(String[] args) {
MSVCRT.Instance.printf("Hello, World\n");
for (int i=0;i < args.length;i++) {
MSVCRT.Instance.printf("Argument %d: %s\n", i, args[i]);
}
}
}
> "C++ is more popular for systems programming"
Sure, and it's got many great libraries – but actually using those is horrible.
You're absolutely right about Rust though. crates.io and cargo are amazing tools with a great ecosystem.
The primary issue I've got with the .NET ecosystem is actually closely related to that. Because it's so easy to import native libraries, often there's no .NET version of a library and everyone uses the native one instead. But if I actually want to build the native one I've got to work with ancient C++ build systems and all the arcane trouble they bring with them.
> Same applies to "packages that bundle native libraries".
You seem to have misunderstood. The fun part of the maven ecosystem is that a dependency doesn't have to be a jar, it can also be an XML that resolves to one or multiple dependencies depending on the environment.
> The primary issue I've got with the .NET ecosystem is actually closely related to that. Because it's so easy to import native libraries, often there's no .NET version of a library and everyone uses the native one instead. But if I actually want to build the native one I've got to work with ancient C++ build systems and all the arcane trouble they bring with them.
What is the reason to continue making statements like this one? Surely we could discuss this without trying making accusations out of thin air? As the previous conversation indicates, you are not familiar with C# and its toolchain, and were wrong on previous points as demonstrated. It's nice to have back and forth banter on HN, I get to learn about all kinds of cool things! But this happens through looking into the details, verifying if prior assumptions are still relevant, reading documentation and actually trying out and dissecting the tools being discussed to understand how they work - Golang, Elixir, Swift, Clojure, etc.
> You seem to have misunderstood. The fun part of the maven ecosystem is that a dependency doesn't have to be a jar, it can also be an XML that resolves to one or multiple dependencies depending on the environment.
Same as above.
> JNA
I was not aware of it, thanks. It looks like the closest (even if a bit more involved) alternative to .NET's P/Invoke. Quick search indicates that it comes at an explicit huge performance tradeoff however.
This uses Win32 API. I will post numbers in a bit. .NET interop overhead in this scenario usually comes at 0.3-2ns (i.e. single CPU cycle which it takes to retire call and branch instructions) depending on the presence or absence of GC frame transition, which library loader was chosen and dynamic vs static linking (albeit with JIT and dynamic linking the static address can be baked into codegen once the code reaches Tier 1 compilation). Of course the numbers can be presented in a much more .NET-favored way by including the allocations that Java has to do in the absence of structs and other C primitives.
> Quick search indicates that it comes at an explicit huge performance tradeoff however.
That's definitely true, but it should be possible to reimplement JNA on top of the new FFM APIs for convenient imports and high performance at the same time.
> Of course the numbers can be presented in a much more .NET-favored way by including the allocations that Java has to do in the absence of structs and other C primitives.
Hopefully Project Valhalla will allow fixing that, the current workarounds aren't pretty.
I fully agree though that .NET is far superior in terms of native interop.
> As the previous conversation indicates, you are not familiar with C# and its toolchain,
I've been using .NET for far over a decade now. I even was at one of the hackathons for Windows Phone developers back in the day.
Sure, I haven't kept up with all the changes in the last 2-3 years because I've been so busy with work (which is Kotlin & Typescript).
That said, it doesn't seem like most of these changes have made it that far into real world projects either. Most of the .NET projects I see in the real world are years behind, a handful even still targeting .NET Framework.
> were wrong on previous points as demonstrated.
So far all we've got is a back and forth argument over the same few points, you haven't actually shown any of my points to be "wrong".
> I've been using .NET for far over a decade now. I even was at one of the hackathons for Windows Phone developers back in the day.
This conversation comes up from time to time. It is sometimes difficult to talk to developers who have a perception of .NET that predates .NET Core 3.1 or so and newer. Windows Phone and its tooling is older. I am sad UWP has died, the ecosystem needs something better than what we have today, and the way Apple does portability with MacCatalyst is absolutely pathetic. In a better timeline there exists open and multi-platform UWP-like abstraction adopted by everything. But these were other times and I digress.
The package distribution did not change significantly besides small things like not having to write .nuspec by hand in most situations. Nuget was already good and far ahead of the industry at the time it was introduced.
The main change was the switch to SDK-style projects files. Kind of like Cargo.toml but XML.
Adding a file to a nuget package (or anything else you build) is just adding a <Content ... /> item to an <ItemGroup>.
As you can see, it is possible to make definitions conditional and use arbitrary information provided by the build system. It is very powerful. I don't know what made you think that I assume anything about .jar files.
Together with <PublishAot> property, invoking 'dotnet publish -o .' calls into cargo to build a static library from Rust, then compiles C# project, then compiles the produced .NET assemblies to native object files with ILC (IL AOT Compiler), and then calls system linker to statically link together .NET object files and a Rust object file into a final native binary. The calls across interop, as annotated, become direct C ABI calls + GC poll (a boolean check, multiple checks may be merged so less than a branch per call).
This produces just a single executable that you can ship to users. If you open it with Ghidra, it will look like weird C++. This is a new feature (.NET 7+) but even without NativeAOT, it was already possible to trim and bundle CIL assemblies into a single executable together with JIT and GC. As far as I'm aware, the closest thing that Java has is Graal Native Image, which is even more limited than NativeAOT at the present moment (IL linker has improved a lot and needs much less annotations, most of which can be added as attributes in code and the analyzer will guide you so you don't need trial and error). And the project that allows to embed bytecode in the .NET trimmed single-file style in Java is still very far from completion (if I understood it right).
I think https://two-wrongs.com/dotnet-on-linux-update is more or less representative of unbiased conclusions one makes when judging .NET by its merits today. You can always say "it used to be bad". Sure. It does not mean it still is, and the argument is irrelevant for greenfield projects, which is what I advocate C# is the better choice for anyway.
> I fully agree though that .NET is far superior in terms of native interop.
This is not limited to native interop. At its design inception, C# was supposed to replace C++ components at MS. Then, in C# 2, a focus group including Don Syme if I'm not mistaken pushed for generics and other features. Someone posted a history bit here on HN.
This and influence from the projects like Midori (spans, struct improvements), and subsequent evolution (including the existence of Mono) and especially after it stopped being .NET Framework and became .NET resulted in a language that has much wider scope of application than most other GC-based languages, including Java, particularly around low-level tasks (which is also why it's popular in the gaming industry).
Unfortunately, the perception of "another Java" hurts the ecosystem and discourse significantly, as the language and the platform are very unlike this claim.
> NET Multi-platform App UI (.NET MAUI) apps can be written for the following platforms:
> - Android 5.0 (API 21) or higher is required.
> - iOS 11 or higher is required
> - macOS 11 or higher, using Mac Catalyst.
> - Windows 11 and Windows 10 version 1809 or higher, using Windows UI Library (WinUI) 3.
Okay, where's Linux? That's what Mono was originally made for and where Mono really shines.
Also, the development experience isn't great either:
> - If you are working on Linux, you can build and deploy Android apps only
> - You need a valid Visual Studio or IntelliCode subscription
The getting started guide only exists for Windows and macOS and the forum post announcing experimental Linux support is full of caveats.
I don't think you and I would agree on what "cross-platform" means, especially in the context of Mono being donated to Wine, which is a heavily linux-centric discussion topic.
> - 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 file in the solution, though I use neither)
While I don't have much direct experience with it, as it was easy to migrate my personal projects, it seemed the idea was sound. It seemed like it was a way to encourage people to write libraries against the new .NET Core (at the time) but still allow those libraries to be used in .NET Framework as a sort of bridge for people stuck on .NET Framework.
Any support for open source or cross-platform stuff was a bulwark against claims of monopoly abuse, but none of it worked well enough to be a true replacement. Mono worked for some purposes, but it was far from the first party support cross-platform .NET gets today. Nowadays it sounds like .NET Core + third-party GUI libraries is the way to go.
> Nowadays it sounds like .NET Core + third-party GUI libraries is the way to go.
For reference for those unfamiliar with the terms:
.NET Core was the name given to the cross-platform fork of the .NET runtime.
It was forked out of .NET 4.x and dropped support for a lot of things in the first versions.
It ran on various distributions of Linux and MacOS.
At the same time there were forks of other libraries/frameworks in the .NET ecosystem to have 'Core' variants. Often these were dropping support for legacy parts of their code so that they could run on Core.
Later versions of .NET Core brought over support for a many of the things that had been dropped.
.NET Core and .NET had stand-alone versions until .NET Core was renamed to . NET and became .NET 5.
So, if you want to do the most modern cross-platform C# you would use .NET 9.
More or less. any version of .NET >= 5 is cross-platform and is a direct descendant of the "Core" side of the fork, and so has no "full framework, windows only" variant.
It is "Core" in a lineage sense, but there's no need to make that distinction any more. The term "Core" is out of date, because the experimental "Core" fork succeeded, and became the mainstream.
I've been a long way from Windows development for a while, so missed that shift. I knew it was coming since moving functionality to the open source thing seemed to be Microsoft's target (with some skeptics doubting it, understandably). I didn't know it already happened.
The shift is slow, but it has been ongoing for years, and is pretty much wrapping up now. .NET 5 was released in November, 2020 and that was the "beginning of the end" of the shift over.
For what I do, it's not really "Windows development" in any meaningful way. It is business functionality with HTTP, message queues etc, developed on mostly Windows laptops, and deployed to mostly Linux instances on the cloud. Not that the host OS is something that we have to think about often.
For this, .NET 3.x "the full framework windows only version" services are regarded as very much legacy, and I wouldn't go near one without a plan to migrate to a modern .NET version.
However, YMMV and people are also making windows desktop apps and everything else.
Quantity of languages might be less important than: how many needs are served by those languages, whether the ecosystem is dynamic enough to keep expanding served niches, and whether the culture and community is likely to produce language support for a niche that matters to you ever or on a realistic timeline. The JVM does appear to have a lot more niches covered, but you can still do all the things those languages do in what's available for the CLI.
I don't know much about the current state of CLI and .NET beyond what I've read here, but it sounds like it's dynamic enough to keep expanding. I also don't know enough about the long tail of niche languages supported by each to know which direction they're headed.
That's the situation with the tools used for music production. In theory, any DAW (Digital Audio Workstation) can make any kind of music. In practice, they all move toward different kinds of music, and you'll run into increasing friction as you do weirder or more complex stuff if you pick the wrong DAW. Cubase can do electronic music, but you're better off with FL Studio or Live. Live and FL Studio can do orchestral, but you're better off with Cubase.
And I'd guess there's a similar dynamic with CLI and JVM and the languages that target them.
It's a fork with a lot of modifications (mostly removing deprecated stuff and making it cross-platform). You can still see a lot of ancient stuff in the sources such as referring to the base Object class as "COM+ object" (.NET was originally envisioned as a successor to COM).
>An early name for the .NET platform, back when it was envisioned as a successor to the COM platform (hence, "COM+"). Used in various places in the CLR infrastructure, most prominently as a common prefix for the names of internal configuration settings. Note that this is different from the product that eventually ended up being named COM+.
Correct, the bytecode wasn't even 1:1 compatible. They then brought over missing pieces, and consolidated .NET Framework features into .NET Core, thus becoming just .NET to end the dumb naming war, since everyone calls it .NET anyway...
Good write up that wonderfully encapsulates how stupid Microsoft’s naming is - you didn’t even mention .NET standard.
I love .NET. It’s a great stack, especially for backend web apps. Blazor is a great SPA framework too. But I loathe how Microsoft continue to handle just about everything that isn’t the framework and C# / F#. It’s laughable.
Oh don’t get me wrong - I wasn’t criticising your write up. It was concise and still relevant.
It’s just funny for newcomers to peel back the onion more. Writing a source generator? Target .NET standard 2.0 (not even 2.1) for a whole host of reasons.
The ".NET" label was applied to a bunch of things at Microsoft.
It was also an early name given to their social networking / IM things.
But for the last 20-ish years it's really only been applied to things related to the .NET Framework.
So, yes - Visual Basic.NET is a language - it's the language that replaced Visual Basic 6. It compiles to the Intermediate Language (IL) that the Common Language Runtime (CLR) executes. There are other languages that compile to IL, too like C#, F#.
The .NET Framework is really a bunch of libraries and tools that are packaged together.
The .NET Standard is a standard that allows you to build a library to a known set of supported libraries and IL / CLR features.
So, yes, depending on which specific part you're referring to - it's all of those.
The "Xbox Series X" is such a nonsensical name that only a marketing department could come with it. And this entire line of names exists solely because someone thought that nobody would buy a "Xbox 2" instead of a "PlayStation 3".
Because X's mean moar marketing power... Like the Extreme X870E X motherboard... There's multiple X's and Extremes and the X's mean extreme... so it's moar extreme!!!
Among the other small nits in your otherwise concise post... the windows only versions of .NET (1-4) were known as .NET Framework. So, Framework is the only windows only version, followed by Core being a limited feature set but cross platform and then .NET 5 (no suffix) being a full featured version that is cross platform.
I'd argue that the dominance of Linux on cloud and Azure growing business is what's causing Microsoft to have an ongoing interest in linux support.
A factoid that's shared sometimes (no idea if true) is that Microsoft now employs more Linux kernel engineers than Windows kernel engineers due to Azure.
That came after. Linux wasn't even on 2.6 with its famous stability yet when this kicked off. What you see now is a result. They softened on open source as they realized it actually has some benefits for a company like Microsoft.
The Microsoft of the Halloween Documents[0] is a different Microsoft from the one we see today that understands open source as something good rather than as a threat, and it started with Microsoft being forced to play nice.
After having gouged Red Hat and Suse for years with their bogus Linux patent racket and bankrolling the infamous SCO Unix lawsuit. Make no mistake M$ coming over all We Love Linux was like Donald Trump turning up at the DNC.
I do remain skeptical that the node on the Microsoft org chart that usually strangles anything good the companies does is waiting to strike. It used to be Windows node, but now it seems like the ad node comes in for the kill most of the time. The company is slowly morphing into Google as Google morphs into Amazon, while Amazon is morphing into UPS.
Off-topic but to join in the general good vibes this announcement emanates: i have to say that my experience using Azure cloud has been stellar. Their co-pilot integration works well, IME. Azure shell is simple and good. Dashboard UI is always good.
Bona fides: I have used GCP for 3 years, AWS for 3 years, and Azure for ~ 1 year. As well as the more "bare-metal" types of cloud providers like Linode/Akamai, and Vultr -- all the latter of which are great for self managing your infra.
I also really find the ability to spin up Windows Server and Windows 10/11 etc super useful for builds, testing, Hyper-V.
I really like Azure for huge projects with many moving parts.
More like it was shoring up for developers who use and/or target mac and linux. Many devs are using macs and targetting linux for deployments. MS wants Azure to be a first class option for developers and is the focus for making money going forward. It makes sense for their developer tools to offer that.
Azure didn't exist. OS X had just come out and almost no one took Macs seriously as a development target yet. Windows was the only user-facing thing anyone developed for aside from little Java games on flip phones. The Web 2.0 takeover was still years off and Internet Explorer ran the show.
Is "historical context" not as clear as I thought? You're the second person to challenge this by pointing out the current situation when I'm talking about how we got here.
Then you're not talking about what I was talking about in the post you replied to with a framing that suggested you were disagreeing. Did you click the wrong reply link?
Mono implemented the GUI stuff like Windows Forms, do the latest windows cross platform stuff support that? Can you run .Net GUI windows program on linux without Mono but using the latest .Net thing ? I know it was not possible in the past.
The whole point of .NET-Core was to remove all the (largely desktop-oriented) platform-specific dependencies that tied it to Windows, so you could run server-oriented .net programs on Linux. So no, afaik you can't simply run GUI apps built with .Net on Linux desktops - that's the reason Mono wasn't simply killed, because it covers that niche (which wouldn't even exist, were it not for Mono/Xamarin's efforts back then. But I digress...). Nowadays there are a few other attempts at providing that UI layer.
.net Core still has Windows Forms thoguh? At least I (for kicks) migrated one of my old .net 4.something projects to .net core and it still works and shows the classic Windows Forms GUI.
.Net Core on Windows has support for loading assemblies that reference COM interfaces and the win32 API, along with other things that aren’t supported elsewhere like C++/CLI.
That’s why loading System.Windows.Forms still works, it’s not part of .Net 5+, but it can still load the assemblies on Windows (they still use GDI, etc under the hood).
Sure, nobody wants to write Winforms new applications today
My point is about running existing applications on Linux,
there are still issues with running .Net GUI stuff under wine and Mono was not a perfect implementation.
I read in other comments that the newer .Net cross platform stuff is not a replacement for Mono for running this old applications. (nobody will rewrite them to use the current GUI stuff from MS since are old apps)
No, Microsoft's .NET only supports WinForms on Windows. They do have an official cross platform GUI toolkit in MAUI, but it strangely does not support Linux.
Last I knew it is also considered pretty lackluster. Every time I read up on it it feels like, even beyond the lack of Linux support people just don't care for it.
If I was building a cross platform native app with .NET I'd probably use Avalonia right now.
Yeah, the took an age delivering it, then it came out and most of the early reports were “It’s still not ready.” and then I think Microsoft just gave up.
I think not supporting Linux was a tactical error, though. Some people will put up with a lot for Linux GUI support, and some of those people are the types who can resolve problems with your half-baked GUzi framework.
Does it really need help? I struggle to imagine a scenario where one would consider MAUI not supporting Linux to be an issue (if we discard superficial bad faith concern) when Avalonia, Uno or, if you care about Linux as the main target, Gir.Core exist.
And, at the end of the day, you have a tool with an extremely rich FFI capability so whatever is available from C you can use as well.
Sorry I clearly was not clear enough. I mean specifically an issue with MAUI itself. I agree dotnet/c# have some solid UI options cross platform at this point. MAUI however seems to be at best a mess and at worst dead in the water.
> "The future is already here – it's just not evenly distributed."
Were I live and work (IT and consulting in central south-east Norway) it has been the year of the Linux Desktop on and off since 2009.
That was the first time I worked full time at a place that deployed Linux for everyone and everything that didn't have a verified reason for needing Windows.
I think we had one 3rd party trading software running on a Windows machine and maybe the CEO and someone in accounting got Windows.
Everyone else was upgraded to Linux and it worked beatifully. It was my job to support the sales department with desktop related issues and it was absolutely no problem to do it while also being a productive developer.
Since then I have not worked on a place that required Linux, but I think most of the places I have worked on since has had Linux as an option as long as you supported it yourself, and some places also have been very active writing how-tos and working with me to troubleshoot issues that were related to Linux, since many of them were also Linux users.
At the moment I use Mac, but at my current job I'm also allowed to use Linux.
Open Source Support reasons. If Linux developers want better MAUI support there is a "Community Repo" to contribute to and help move things further along. The impression is that if things were further along it might get formally "adopted" (by the Dotnet Foundation) for "official" out-of-the-box "support", but it isn't far enough along and doesn't seem to have enough contributors with enough momentum. It currently seems that the Venn Diagram of "Developers that say they want MAUI support for Linux" and "Developers that would contribute to Linux support for MAUI" has too small of an intersection.
Sure, Microsoft could pay more employees to work on it faster, but Linux loves and prefers open source from Linux devs "untainted by Microsoft", right?
Contribute to the Maui backend for GTK and/or Qt, nothing is stopping you
Alternatively, just because you're on .NET doesn't mean you need to use Microsoft sanctioned UI toolkits, just as C++ has no "official" UI toolkit. You're free to pick up some GTK or Qt bindings if you want a native feeling and your application is already architectures correctly. Alternatively, throw Imgui at it if you just need dev tooling, or maybe try other cross platform toolkits in the ecosystem like Avalonia or Uno
It is not perfect, there are issue depending if you need 32 or64 bits or if you need .net4 or greater. Games work but I have issues running tools like mod managers, game save cleners that are made with .net . In my case Sims3 works fine but not the Sims3 Launcher(this tools has more features then just launching the game like importing custom content/mods )
Sadly some Java tools stopped working if you run latest Java runtime because for some reason some crap was removed from Java and nobody made some easy way to add them back with soem package install.
With commercial applications that want to just take their existing code and have it run on Linux with only a couple lines changed, Avalonia XPF will do that
You are expected to use Avalonia or Uno for multi-platform targeting or Gir.Core (GTK4) or one of the many other binding libraries for Linux-specific GUI.
Also very easy to throw something together on top of SDL2 with Silk.NET.
Practically speaking it is in a much better place than many languages considered by parts of Linux community to be more """linux-oriented""".
My personal use case is running old GUI apps, I am not planning on writing GUI apps with .Net , MS had the opportunity to open source .Net/Silverlight and make money from tools but they bet on Windows and today most apps are node and javascript, a much inferior platform but MS open things up too late.
No, they pretty much gave up on winforms when .net core morphed into "the" .net that is cross platform. There are some nice crossplatform gui libs now though.
If true this would be huge. I got burned on the whole silverlight, Universal Windows Platform, WPF etc. All these new and improved solutions had all sorts of issues, no designer, no or weaker accessibility stories, bloated, slow etc etc.
C# + Winforms would be appealing. Some of the performance with larger datasets in the new solutions (tables etc) was just surprising. I really feel like Microsoft got so distracted chasing phones, tables, touch etc they forget just basic line of business application development which they could and should have owned.
.net Core doesn't supply WinForms, but WPF is the far more common paradigm for Windows apps now. WPF is supported by projects like Avalonia on Linux. There are also a few other major alternative UI toolkits, more commonly used by cross-platform (vs Windows-exclusive) developers.
This is the "virtual monorepo", if you want to clone one repo and build the entire SDK product then this is the correct thing to checkout - but development work right now still happens in the separate project repos, of which there are ~20
No it's way better than Flutter. Avalonia really works on desktop.. :). Also the model is WPF so whoever know a little bit of legacy .NET framework will be able to write Avalonia apps in no-time
I don't know any .net, and have never heard of this until now. Only stories with comments on HN are from eight years ago. Although I liked the screenshots on the linked site, it doesn't seem to have much buzz around it.
And unfortunately, the only stench I can't stand more than Google's is Microsoft's.
I do not follow buzz. I am an engineer by education and attitude and always try to investigate my options based on my needs and requirements. I use buzz only to drive me trough my investigations. In my case I had a desktop application that had to run on Windows and MacOs and needed support for Rich text format and rendering of custom graphs.
Following buzz I started to do a prototype with Flutter and stopped after a few days as I found out that most of the open source controls I was using had bugs on Windows Desktop. Then I moved to MAUI and discovered that in order to have some decent Rich Text support my only option was Blazor Hybdrid. Nedless to say I found bugs that prevented my prototype to work correctly. Then I moved to UNO and found that it doesn't have full Rich text format support. I was able to find some .NET open source libraries for doing text layout on Skia and with that I was able to find a partial solution that was however pretty complicated. Out of curiosity I investigated Avalonia and found that everything that I needed had full support. Being fluent in WFP I built the prototype in 3 days and I never looked back.
Your experience might vary depending on your fluency of WFP but I found that, considering Windows Desktop as a target platform, Flutter and MAUI are absolutely the worst options.
In my opinion Uno is better than Avalonia when considering web application support but Avalonia has more coverage of the WPF api with respect to what Uno does for WinUi. And for sure marketing is the worst part of Avalonia while it is the BEST for MAUI and Flutter.
BUT
That's now officially unsupported as all of Xamarin Forms is no longer supported and the MAUI replacement doesn't cover Linux nor does that look likely (MAUI is mired deep in problems due over-ambition, failure to resource and it seems a significant push in MS to use MAUI Hybrid aka web UIs within native apps).
Yes. There are multiple UI projects that build on the WinUI 3 components in the Win App SDK.
There's the first party MAUI which is an updated version of Xamarin Forms. The two best-known third-party implementations are AvaloniaUI and Uno. I prefer Uno, it has more cross-platform targets.
Which lets you run Blazor (web framework) like a desktop UI across all major desktop platforms. Microsoft has MAUI/Blazor as a thing, but only targets Mac and Windows ATM, so Photino bridges the gap for Linux.
Photino lets you use anything other than just .NET but has pretty decent .NET support.
(i hardly know what i'm talking about so somebody else may have a better idea, but i'm here now so)
mingw is a GNU's header/library environment (tools too maybe?) to create windows compatible applications. So I'd look into searching mingw .net and/or mingw mono.
also, ask your favorite AI, they're good at this type of question so long as it's not up to the minute news
> 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,
.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.
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.
It's even worse, since they dropped the core now and just call it .NET.
So searching has become even more of a pain.
It's also pretty much a mess, because many things were different between the versions.
So let's say you google how to do something and the result could be:
I think Microsoft is completely allergic to naming anything with a unique name or term; in fact, it's almost like they pick names that will be hardest to find with a google search.
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.
Aside from following the default 'start here' documentation, there are various timelines made for fun and profit that visualize the full history, for example:
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.
> 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.
Is there good documentation somewhere for getting set up to develop with modern .NET on Linux?