[bmitc]

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.

[safety1st]

This is wild, apparently this stuff is in the Debian repos now? https://learn.microsoft.com/en-us/dotnet/core/install/linux-... So you can just apt install dotnet-sdk-8.0.

This must be the most unfriendly Linux install documentation I've ever seen though, it was not easy to find the names of those packages.

[frankjr]

> This is wild, apparently this stuff is in the Debian repos now?

It's not. Microsoft provides its own apt repository you need to add first.

[sander1095]

Some distributions have it in the standard apt repo, like Ubuntu.

[notpushkin]

It's in a bunch of other distros, though: https://repology.org/project/dotnet/badges

[safety1st]

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

[tracker1]

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.

[Intralexical]

Huh, why isn't it in?

Does it not meet the DFSG?

[zokier]

The Request For Packaging arrived a week ago, its all still very fresh and new: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1078132

[bmitc]

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.

[posguy]

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

[nickcox]

> This is wild, apparently this stuff is in the Debian repos now?

It's been there for several years now, hasn't it?

[gymbeaux]

Not Debian, but some Debian-based distros

[tomkarho]

> It's fully-cross platform

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.

[rahkiin]

That is like saying C is not cross platform because there is not a library for making desktop apps that use native components on all those platforms.

[quietbritishjim]

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.

[pantalaimon]

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.

[toyg]

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

[chgs]

Visual J++ was Microsoft’s Java

[toyg]

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.

[lelanthran]

Same with java - designed for embedded set top devices, pivoted to backend services.

[kuschku]

.NET/C#'s competitor JVM/Kotlin does provide a UI framework (Jetbrains Compose) that runs on iOS, Android, Windows, Mac, Linux, and the web.

That's what you have to compare against, and .NET/C# falls flat.

[pjc50]

That's also not part of the JVM or the Java language.

[notpushkin]

Jetbrains is a third party vendor here, too.

[kuschku]

A third party vendor for the Kotlin language? Kotlin has replaced Java as C#'s largest competitor, so that's what we should be comparing against.

[toyg]

> Kotlin has replaced Java as C#'s largest competitor

Er, I don't think this assertion is backed by data. See for example https://pypl.github.io/PYPL.html

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.

[neonsunset]

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.

[kuschku]

Which rich cross-platform GUI frameworks are you talking about?

Win32? Silverlight/Blend? XAML? MAUI? They're all windows only.

Gtk? Qt? Sure, they exist, but they're ancient and limited to long outdated paradigms.

I don't know if you can get QtQuick with KDE Kirigami to work on .NET, otherwise that might be one option.

Kotlin Multiplatform is btw a solution for building the same code for kotlin native, JVM and web to target all the OSes at the same time.

While Jetpack Compose is the Android Version of Compose, Compose Multiplatform is Compose for Kotlin Multiplatform.

> subject to the quirks and specifics of JVM implementations, build-systems and package management

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.

[neonsunset]

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?

[hermitdev]

> Which rich cross-platform GUI frameworks are you talking about? > Win32? Silverlight/Blend? XAML? MAUI? They're all windows only.

MAUI is not windows only. I have a MAUI app on my android phone. Cross-platform? yes. Rich? Now, I wouldn't call it that.

[gymbeaux]

Oh my god I forgot about .NET Standard. What were they thinking…

[bmitc]

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.

[anymouse123456]

PSA for new players.

Do not under any circumstance trust Microsoft for anything at all.

They have a decades-long history of treating their best customers with contempt.

They will break or deprecate whatever you rely on, and they will do it without warning.

[nobodyandproud]

If only. Class libraries still have to worry about this.