Who is using .NET on Arch or Manjaro? Is the experience good?

[richlander]

I'm an Arch and Manjaro user. I was wondering if anyone else was using .NET on Arch family distros. If so, please tell me about your experience or at least provide an upvote. I want to know if there is anything more we can do for Arch family users. Please pass on this request to other .NET users on Arch family distros.

Current support matrix: https://github.com/dotnet/core/blob/main/release-notes/6.0/supported-os.md

Reddit:

• https://www.reddit.com/r/archlinux/comments/n0sjfc/are_you_using_net_on_arch_linux_is_the_experience/
• https://www.reddit.com/r/ManjaroLinux/comments/n0ohdw/who_is_using_net_on_arch_or_manjaro_is_the/

FYI: Here's a post about using .NET on Manjaro: https://devblogs.microsoft.com/dotnet/show-dotnet-animating-40-leds-with-charlieplexing/

[omajid]

cc @alucryd @ettolrach @laktak

[laktak]

The dotnet packages were outdated for a few months but the installation via AUR worked without a hitch. Still, it would be nice if Arch was an officially supported platform to avoid such issues in the future.

Other than that I encountered no problems.

[ettolrach]

Yeah, in the official repos the -sdk, -runtime, and -host packages were stuck on .NET Core 3 instead of .NET 5 for over half a year. They said that this was because they had troubles getting it to compile correctly, but there was an AUR package which did support .NET 5 called dotnet-sdk-bin. I'm not sure what the issue was since I wasn't interested in helping, but nevertheless, the packages in the official repos was updated to .NET 5 somewhat recently and has so far been kept up-to-date.

Except for the maintainers sometimes being late, or in this case very late, on an update, using the language is absolutely fine and I haven't experienced an issue with it yet that I wouldn't have also had on another platform.

[alucryd]

Not exactly a heavy user as I don't write C#, so my use case is just running emby and so far I had zero issues.

There are various reasons why packages are often out of date:

• the build process breaks with almost every release and requires new patches to work, this is a 1h build even on a beefy build machine, so on a good day I have maybe 4 attempts at getting it to build
• not all releases are tagged on the source-build repository, e.g. 5.0.201

The AUR package on the other hand just extracts official tarballs, so that's an easy one.

[Gr3q]

@richlander Thanks for the email, yes I'm the maintainer of the AUR packages.

I can confirm what @alucryd wrote, packaging the AUR package is very easy, I just have to make sure files end up at the right places (so no issues there).

Similarly I wanted to use Jellyfin - a fork of Emby - on my Arm64 Arch install and contribute to it. It might be worth sharing this thread on the archlinux subreddit with the same question if you want to reach more people.

As for help, if you can make it easier for the official package maintainers to build, that would be definitely much appreciated.

[richlander]

We have a new project for source build that that is oriented on making it (A) much easier/cheaper to ingest and build .NET from source, and (B) to release updates on our schedule. I've asked the folks who work on that project to engage on this issue. We're having a similar conversation with the Alpine Linux folks. We've also worked with the Red Hat and Fedora folks for a long time. It might be useful to setup a (public) forum for .NET distro maintainers. Would that be interesting?

[crummel]

@alucryd @gr3q Hi, I'm that source-build guy! Do you have some specific asks on making it easier for package maintainers to build? Like Rich says, we do have some work in progress that should help out a lot with each release needing in-depth work (https://github.com/dotnet/source-build/issues/1510), but if there's something quick we can do in the meantime I can definitely bring it up. I checked out some of your patches and some of them seemed like version differences between our configuration and yours (clang versions, linker issues, warnings) - is that most of the problem?

[alucryd]

@crummel Thanks for chiming in as well.

You are correct, these are the remaining issues (which are standard due to our rolling nature, so no worries there). The last version was fairly painless all things considered, well apart from that nasty nuget certificate situation. The various RID issues seems to have finally died down, and the ICU 68 patches have been merged so I was able to remove those. Also the tools are correctly installed in the latest release, they were missing in the previous one. So kudos to you guys.

There is one issue I've had complaints about but it seems you're working on it already: https://github.com/dotnet/source-build/issues/2006 I was able to reproduce that one, reverting the patch that disables this particular build does end up in failure.

In terms of specific asks, it would be great to get Arch into the CI matrix for source-build. We've discussed it already on another issue. And as always I was bargaining with time I don't have so I'm well overdue in making PRs to get this done, hopefully I can get to that sometime in 2021 :/

One gripe I have with the current build is that sources can no longer be cached and have to be redownloaded every time. Before I was able to list all git repositories as sources of my package, which made it possible to store these repos in a local cache and skip redownloading everything with every rebuild. This shaved some 15 minutes off builds, and saved a lot of bandwidth. It also made it easy to cherry-pick patches you may already have upstream, or just use a newer commit altogether.

As for dotnet core's popularity on Arch, well I receive more emails when it's outdated or not working properly than all of my other packages combined, from both Arch and Manjaro users, so demand is fairly high.

[medmedin2014]

The official open source "code" package can't install C# extension, and it's only possible with visual-studio-code-bin from AUR.

[medmedin2014]

The most wanted wish by every Linux user is to write and execute WPF/WinForm apps on Linux :) , dotnet core is open source but not totally free because all GUI libraries are still locked and restricted by Microsoft to only Windows.

[richlander]

dotnet core is open source but not totally free because all GUI libraries are still locked and restricted by Microsoft to only Windows.

I appreciate the sentiment, but I don't quite share the same world view. WPF and Windows Forms are built on top of Windows (as you know). It would be a major project to make them work on Linux. All of the code for WPF and Windows Forms is open source up to the point of what we consider the Windows platform. I think it's fair for Microsoft to say "we're not signing up for porting these projects to Linux (or any other OS)" w/o others saying that "all GUI libraries are still locked and restricted by Microsoft to only Windows." It is the phrase "locked and restricted" that I take issue with.

I wish grep was in Windows. Thankfully curl, ssh, and tar are. I would never characterize the Linux ecosystem of "locking and restricting grep to only Linux". I feel like that's a reasonable analogy. If it is not, where does it fall down? Put another way, what is the nature of the "locking and restricting" that you see? If it's failure to act, then those terms don't seem to apply.

I'm trying to reach out to the Arch and Manjaro communities, so am wanting to avoid dissonance. That said, I hope there is room for me to describe my take on your comment.

[richlander]

so demand is fairly high.

@alucryd -- that sounds great. Is there any sort of data you can share with us that helps us quantify that? That will help motivate increasing our support / collaboration.

[ghost]

What about asking in r/linux? It has a much bigger base, and you'll get more responses

[richlander]

Sure. That's a great idea for a second round. I wanted to start with a particular distro family that I knew was underserved.

[alucryd]

@richlander We don't collect any data so getting accurate numbers is somewhat difficult, we do however have a package statistics tool that users can install, but it is entirely optional and not many people know about it. Still, around 12% of pkgstats contributors have the dotnet-runtime installed: https://pkgstats.archlinux.de/packages#query=dotnet

And if you have a look at the AUR, the bin packages are in the top 200 popularity-wise (among 70000 packages): https://aur.archlinux.org/packages/?SB=p&SO=d&O=150

Hope this helps.

[hartmark]

I'm a full time developer on .net platform on Windows. I have only Linux machines at home, so I wanted to try out writing a simple webapi for some hobby project. I haven't had much time to work on it but the skeleton service was up and running in five minutes.

So in short. My experience in arch was quite good so far.

[Gr3q]

The only quantity of users I have is the number of upvotes on this thread 1 year ago, which more or less means at least 200 people were dissatisfied of the state of the packages at that time. (Side note: basically I took ownership of the AUR packages then and updated them based on that post, credit to u/Saancreed)

~r/archlinux is a better choice over r/linux if you want to reach archlinux users~ See you've done this already

[laktak]

One issue I remembered: dotnet new still creates \r\n on Linux. This has been partially fixed.

[medmedin2014]

WPF and Windows Forms are built on top of Windows (as you know). It would be a major project to make them work on Linux.

So this is the chance to completely free dotnet core from Microsoft and Windows (if it's truly free) and create new cross platform GUI library (which I think will never be achieved due to money poured on dotnet core devs by Microsoft), the low level layers of dotnet core are already stable and run well on Linux what is needed is just GUI top layer that runs on top of it, the pretext of being dependent on Windows libraries is not valid anymore because the ground is already paved to do it with dotnet core, and the possibility of success is high because there are already successful cross platform solutions like JavaFX, GTK, Qt, Electron, Flutter... Microsoft is doing the opposite to grab Linux users attention by giving the possibility to run Linux OS and apps on Windows (via hidden virtualization), but if forgot the essential reasons why devs and users abandoned Windows : Privacy and failed upgrade process for desktop users and poor Windows Server performance and security for Web devs.

[Gr3q]

So this is the chance to completely free dotnet core from Microsoft and Windows

@medmedin2014 This is not, it is a discussion about how to support dotnet/core better on Arch based distros (and public interest for it).

If you want official Linux support for a GUI library, a better place raising your concerns would be here and here https://github.com/dotnet/maui/discussions/339

[richlander]

@laktak -- If you could, could you file an issue at dotnet/sdk on the line-ending issue? I've seen that mentioned by others.

[laktak]

@laktak -- If you could, could you file an issue at dotnet/sdk on the line-ending issue? I've seen that mentioned by others.

There is this issue from 2017 already: https://github.com/dotnet/templating/issues/1248

[gustav3d]

I'm using Kestrel with systemD integration to host GRPC on Manjaro. I'm very satisfied with the systemD integration.

The lag of weeks to months between .NET releases and its availability in any of the formal Manjaro repos is my only concern.

[natalie-o-perret]

Manjaro user here, so far so good. Just had some annoying issues with Visual Studio Code + C# / F# plugins and since then I've stopped using them altogether and now rely on Rider instead for all my .NET-related devs.

[ricardoalcaraz]

Hello arch linux user here. Dotnet is awesome. I remember my original install being slightly painful because there was a small burden of knowledge but thankfully we have the arch wiki. I did a clean re-install of dotnet today from the official repos and it is finally up to date🙌🙌.

It would be nice if a dotnet had a package group or metapackage in the repos. I find myself always needing the aspnet-runtime package. It's not a nice experience to have your first WebApi fail to run because it's not installed. I can't remember the error message that was given but it wasn't immediately obvious to me what was missing. Defining a dotnet package group would be a nice addition because you can guide people through an install. It can install the core libs and any additional libraries like aspnet-runtime. https://wiki.archlinux.org/title/Meta_package_and_package_group (I would try this myself but I have no time these days). This would help smooth brains like me install it effortlessly through pacman as I'm typically used to.

Another thing I'm concerned about is versioning. .NET 3.1 is still officially supported and receives upstream patches but it's not available in the official repos. I'm a little hesitant to use .NET for new projects because of the breaking changes introduced by every major release which releases every year. Long term release have 3 years of support which will give me and other devs plenty of time to upgrade before it's dropped from the official repos. Maybe with the groups addition we can even have guided install that allows us to select which officially supported versions we want.

[alucryd]

It would be nice if a dotnet had a package group or metapackage in the repos. I find myself always needing the aspnet-runtime package. It's not a nice experience to have your first WebApi fail to run because it's not installed. I can't remember the error message that was given but it wasn't immediately obvious to me what was missing. Defining a dotnet package group would be a nice addition because you can guide people through an install. It can install the core libs and any additional libraries like aspnet-runtime. https://wiki.archlinux.org/title/Meta_package_and_package_group (I would try this myself but I have no time these days). This would help smooth brains like me install it effortlessly through pacman as I'm typically used to.

That can be done, we just don't like introducing groups for so few packages when optdeps are perfectly fine. That I'll add in the next release. I'll keep it in mind.

Another thing I'm concerned about is versioning. .NET 3.1 is still officially supported and receives upstream patches but it's not available in the official repos.

Not sure where you got that, we have the whole 3.1 stack: https://archlinux.org/packages/?q=dotnet-runtime-3.1 Also, you could always use AUR if we didn't. Admittedly 3.1 will probably be dropped when 3.1 packages like emby move to 5.0, but for now we do provide 3.1.

[Gr3q]

The 3.1 AUR packages got hit by a deletion request and were removed when the official ones released (which is I'm a bit sad about because I kept them around for ARM architectures), so only the official ones can be used for 3.1.

[alucryd]

@Gr3q Were they the -bin variant? I'm suprised they were deleted, -bin variants should always be allowed as an alternative to packages built from source, even if they are in the official repos :/

[alucryd]

FYI, latest releases are up in the arch repos. 5.0 built just fine without any change, 3.1 didn't build when bootstrapped with our own build, had to keep bootstrapping with an official build.

[ghost]

Arch user here. I use VSCode and C# for working on an FNA project.

Official support would be nice, as the mono and related packages have been broken and out-of-date for some time now, making it unable to build or run any C# projects.

[richlander]

I'm a little hesitant to use .NET for new projects because of the breaking changes introduced by every major release which releases every year.

The breaking changes have calmed down. I was talking to an internal team at Microsoft today. They were telling us "moving .NET 6 was straightforward." There were lots of challenges moving to .NET Core 3.1. The experience is better after that.

We are getting close-ish to having our build produce source tar balls. We're also thinking about establishing a maintainer network for .NET. That will enable maintainers to more easily produce packages and have better access to the upstream team.

[Joelius300]

Not a heavy user but I never ran into any issues until https://github.com/dotnet/runtime/issues/62554.

[seth-seikosoft]

for the most part I think it's been really nice working with it. I did use vscode when I first switched but the debugging with dotnet is horrible. My company now uses Rider (jetbrains) and it's been great to work with that.

I have recently ran into an issue where I tried to upgrade all my dotnet packages to .Net 6.0 and it throws an error on the "Building dotnet-core-bin... \n ERROR: PKGBUILD does not exist." for the package "netstandard-targeting-pack-bin" do I'm not sure if that's a dotnet specific things or just a packaging with the AUR.

It would be nice to have official packages for all these and their dependencies.

Other than that. Things have been pretty good!

[omajid]

Sounds like a packaging issue with AUR? Maybe @alucryd has an idea?

[Gr3q]

@seth-seikosoft Try to delete your build cache first. dotnet-core-bin provides netstandard-targeting-pack-bin for a while now instead of depending on the one built by @alucryd in case their versions go out of sync (should not make a difference, but still).

Just make sure you have netstandard-targeting-pack-bin installed instead of netstandard-targeting-pack. If you can't build dotnet-core-bin manually at all then the issue is on your system, if you can't build it via an AUR helper then make sure it supports split packages and dependency resolution from the AUR.

[seth-seikosoft]

@Gr3q hey hey that did it.... didn't realize that there was a cached version of the dotnet-core-bin that was the culprit in hanging things up. Thank you very much for that suggestion!

[Juniorsnet]

I use vscode-bin (aur) and dotnet-runtime-bin (aur) because the oficial packages has problem with System.IO.Ports so I use the ---bin packages. apart from that I have not problems.

[alucryd]

@Juniorsnet What kind of problem? Has it been reported somewhere?

[Juniorsnet]

@Juniorsnet What kind of problem? Has it been reported somewhere?

Yep, on https://github.com/dotnet/runtime/issues/62554 and https://github.com/dotnet/runtime/issues/25375