Arch Linux User Repository

IMPORTANT INSTALLATION INFO (a reminder for myself as well):

For dotnet to work you need to EXPLICITLY install:

• ONE dotnet-host - highest version possible
• ANY NUMBER of dotnet-runtimes (and its sdks after if you want to build as well - Right now version 'bin', '3.1', '3.0', '2.2' and '2.1' are tested to work together)

If you keep the install order in mind and you don't rely on pacman to resolve your dependencies you will be fine.

Longer explanation:

Every dotnet-sdk is dependent on a specific version of dotnet-runtime, this is built into dotnet.

Technically you only need the latest dotnet-sdk because it can build to any earlier versions.

Error: Process terminated. Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support.

Found a workaround without installing any new packages, setting environment variable: CLR_ICU_VERSION_OVERRIDE=71.1

Note that you will need to change this variable every time ICU updates until this issue gets fixed

Edit:

This issue only appears if you have .NET Core 3.1 runtime installed alongside 6.0 and your project references Microsoft.NET.Sdk.Functions

@jongeduard

icu 71.1-1 system package downgrade wasn't an option for me, as you mentioned, a lot of other packages depend on it and I didn't want to downgrade all of them.

Thankfully installing icu70 70.1-1 from AUR along side icu 71.1-1 fixed the build and run errors.

I also use storageexplorer AUR for work, it requires 3.1 runtime and it was also crashing on startup with the new icu 71.1-1.

My first attempt to fix the issue was adding DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true environment variable, that allowed me to build the code, but then it crashed on runtime.

Regarding your question what part of the code, there were many but one notable one was Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator

@crimson Thanks, your comment helps me to understand what I am seeing in the VS Code's (using the OmniSharp extension) OUTPUT tab when selecting "Log (Window)".

But I have been seeing an error there for a longer period (I am not fully shure that it was the same, though I know it was a .NET exception stack trace all the time, so I guess it's likely still the same).

Nevertheless I was able to work and my project did simply run, but that's probably because I have not been using that Globalization functionality anywere in my own code yet.

I still have icu-69.1-1-x86_64.pkg.tar.zst and icu-70.1-1-x86_64.pkg.tar.zst in my /var/cache/pacman/pkg folder, but when I try to downgrade to these I am getting conflicts with other dependend packages, so things will become a mess quickly and will probably require me to downgrade or uninstall a whole bunch of things, making everything a mess quickly (I don't expect that the AUR version of those packages will fix that).

So I hope things are getting fixed by others such that this newest ICU version is going to work again.

For my learning experience: what specific code in your projects is using this exact thing?

After updating icu system package to 71.1-1 (International Components for Unicode library) I couldn't build or run some projects anymore.

Error: Process terminated. Couldn't find a valid ICU package installed on the system. Set the configuration flag System.Globalization.Invariant to true if you want to run with no globalization support.

I solved by using CLR_ICU_VERSION_OVERRIDE=71.1

Old solution: installing icu70 70.1-1 from AUR

@Gr3q In my last comment I more or less forgot to metion that I understand this now.

I already found out where you are getting this SDK package from by looking at everything.

I also found Microsofts instruction how I can even simply run this generic Linux package from my home folder by setting two variables - I like the idea of really having the thing installed though, so I'll definitely keep using your PKGBUILD.

I also agree with you that it should be an issue on Github.

Many thanks!

@jongeduard the problem is that I'm not building this binaries, Microsoft is.

If they don't provide them out of the box, the only option is that I download the source and build the manpages myself (like Fedora, but they build everything), which I cannot do because I'm providing binary releases.

This issue might be better directed to the community package maintainers or to raise an issue in one of the relevant packages on dotnet's github, so they provide them out of the box in linux binary releases.

@Gr3q Thanks for your reply. I see.

It's a bit weird with those man pages, I just found out that it's in fedora their dotnet-host package (https://packages.fedoraproject.org/pkgs/dotnet6.0/dotnet-host/fedora-36.html#files).

Maybe this just another extra magic that they did specifically on fedora (as usual) in addition to the defaults. Would not surprise me to be honest.

Never mind. We can look at www.mankier.com anyway and enough docs are on docs.microsoft.com.

@jongeduard probably they have issues building it (as usual), because Arch is not officially supported platform to build on.

manpage info is not included in the prebuilt library and that's why they are missing from this package.

Thanks Gr3q for fixing these .NET packages for Arch. I am giving it a try now, even though I initially wanted to keep my Arch system as Microsoft-free as possible, but .NET is FOSS and very amazing.

I am a developer in C# for many years but I also fell in love with Linux in my free time, especially Arch as well, in which I can control everything myself.

Today I found out about the new Avalonia UI XAML framework which is basically intended to be a new "WPF", but cross platform, I am going to try it now. I discovered this after also reading that the new MAUI framework is not gonna get Linux desktop support yet, but just MacOS and mobile platforms.

One question though: why didn't the official packages on the Community repo receive any updates anymore? They are still stuck on version 6.0.2 from februari, while this AUR version is already at 6.0.5.

Edit: Can I ask a second question here?: I am also running a Fedora system. I noticed that "man dotnet" gives me an entire man page about the dotnet command that I seem to still be missing here on Arch. Is there something I need to configure to fix this, or is this missing in your packages? I don't seem to find any info about it.

@sarvasana Thank you. This version worked!

@vinnivitz and @AkechiShiro Why not use the packages provided by the Community repository instead?

Does anyone else encounters this error? ==> ERROR: PKGBUILD does not exist.

Hi I'm getting the following error while trying to update the pkg :

error: can't build dotnet-core-bin-6.0.4.sdk202-1 (dotnet-host-bin dotnet-runtime-bin netstandard-targeting-pack-bin dotnet-targeting-pack-bin dotnet-sdk-bin), deps not satisfied: dotnet-host>=6.0.4

For the following upgrade :

aur/dotnet-host-bin                 6.0.3.sdk201-1         6.0.4.sdk202-1
aur/dotnet-runtime-bin              6.0.3.sdk201-1         6.0.4.sdk202-1
aur/netstandard-targeting-pack-bin  6.0.3.sdk201-1         6.0.4.sdk202-1
aur/dotnet-targeting-pack-bin       6.0.3.sdk201-1         6.0.4.sdk202-1
aur/dotnet-sdk-bin                  6.0.3.sdk201-1         6.0.4.sdk202-1 

Maybe I need to uninstall reinstall these pkgs ?

@sarvasana I've tested both VSCode and Rider today.

1.) Both automatically detected dotnet, If it does not work on your machine, there might be a misconfiguration issue from the start.

By default most of the stuff detects dotnet install folder by following the symlink from the executable in /usr/bin (this is how this package works) or just uses the env variable set (which might be the case for the install-script, I haven't validated this)

Generally it's a good idea to have a look at both and see where they point to.

2.) I'm happy to validate if the second one is (or was) an upstream issue or not, It would help to have an example proj to test this on. If it's not an upstream issue I will fix the package.

With both the official repository and aur packages for dotnet I had the following issues:

1) Rider could not automatically detect dotnet.
2) Rider could not build MSBuild.Sdk.SqlProj projects.

At some stage I found the dotnet-install.sh script and never looked back again. Maybe these issues are still there, maybe not.

Will check this weekend.

@sarvasana would you specify what kind of issues do you have with the package so at least I could try to fix them?

In my opinion this script is just perfect and it would allow you to pin specific versions for both SDK and Runtime.

That is actually what I am manually doing because I always run into issues with both official arch and AUR packages of dotnet.

From the docs: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script#script-behavior

Regarding installing specific versions:

You can install a specific version using the -Version|--version argument. The version must be specified as a three-part version number, such as 2.1.0. If the version isn't specified, the script installs the latest version.

Regarding SDK and/or Runtime:

By default, the installation scripts download the SDK and install it. If you wish to only obtain the shared runtime, specify the -Runtime|--runtime argument.

@petep Assuming the bug was upstream, can you test this package again? The update came out yesterday, updated it this morning.

If the issue is still present I will investigate further.

I don't use the install script because for a few reasons, but even if I wanted to I probably would break packaging guidelines.

• I can't install a specific version under 5.0 with the script. It's crucial that to know the exact version I provide before install.
• The script downloads the sdk, and it's not in the source array of the PKGBUILD

The latest version at the time of this comment 6.0.100 breaks Microsoft.Data.SqlClient with the error Strings.PlatformNotSupported_DataSqlClient. Removing this package and using the dotnet-install.sh script to use version 6.0.101 fixes things. As @sarvasana - it would be nice to make this more dynamic by using the official script. But I have zero experience with AUR packaging, and therefore don't know how that would play with versioning requirements.

See https://github.com/dotnet/SqlClient/issues/1427

Would it not be easier for all dotnet packages in AUR to make use of dotnet-install scripts provided by Microsoft?

https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script

curl -sSL https://dot.net/v1/dotnet-install.sh | sudo bash /dev/stdin -c LTS --install-dir /usr/share/dotnet

sudo ln -sf /usr/share/dotnet/dotnet /usr/bin/dotnet

You can use that script to install LTS, Current or specific versions such as 3.1.

Honest question.

@Sejsel You are right, thank you for the fix. Pushed an update

To get this package to work properly after the .NET 6 update, I had to edit the PKGBUILD to also copy sdk-manifests in package_dotnet-sdk-bin(). The fixed version is cp -dr --no-preserve='ownership' sdk sdk-manifests templates "${pkgdir}"/usr/share/dotnet/. Without this directory, msbuild throws exceptions complaining about those missing files.

Cool, thanks! And thanks for maintaining this!

@amos fixed, now it can be used with the packages in the community repo

@Gr3q Installing both the repository packages and these packages is sometimes necessary. For building .net 5 binaries I'm using these packages. However if I want to be able to build .net core 3 binaries they are not enough, I have to have the donjet-sdk-3.1 package from the repos, otherwise I get The framework 'Microsoft.NETCore.App', version '3.1.0' was not found.

Is there a reason not to provide (and conflict) netstandard-targeting-pack? This package does indeed provide that.

Regardless, as mentioned before: conflicting and providing netstandard-targeting-pack-bin is redundant, this is already the name of this package.

I'm kinda new to this so I might be confused, but it looks like PKGBUILD says that aspnet-runtime-bin, dotnet-runtime-bin, and dotnet-sdk-bin are in conflict with themselves.

@servime try install dotnet-host-bin, dotnet-runtime-bin and dotnet-sdk-bin all at once if your AUR manager doesn't handle split packages. use just use makepkg -si after you cloned this repo.

@satcom886 .NET is .NET Core, it was simple renamed after 3.1.

@Gr3q Yes, let's add dotNET on Windows too, this is not confusing at all. Ok, so from what I understand:

dotNET Framework - Windows-only libraries and tools for running and developing dotNET programs.
dotNET - Pretty much the same thing, but cross-platform, also without a native ability to create GUIs on Linux (at least until MAUI gets released in v6)
dotNET Core - LTS version of the normal dotNET?

When I try to install dotnet-sdk-bin 5.0.4 in Manjaro from AUR I get this: "target not found: dotnet-sdk-bin", should I wait till dotnet-core-bin is in AUR?

You might be talking about the .NET Framework, the framework running WinForms applications. The normal .NET is .NET Core for a while now (renamed simply as .NET)

Wow, maybe not actually. I remember dotNET being proprietary, while dotNET Core was supposed to be FOSS. Now I'm not really sure. It looks like Microsoft released dotNET as FOSS.

@Gr3q One thing to note is that the packages in the repo are dotNET Core, not dotNET. Normal dotNET is currently at version 5, while dotNET Core is at version 3.1.

AFAIK they are two different things, but often it doesn't matter which one you choose.

The purpose of depending on netstandrad-targeting-pack-2.1 is that you have an option either user netstandard-targeting-pack or netstandard-targeting-pack-bin with the AUR packages.

I don't support using the AUR packages along with the official packages because I can't guarantee that they are up to date (as you can see they are on version 3.1 instead of 5).

My recommendation is to use one or the other, because it is more likely to break if they are mixed than not.

Well, both dotnet-sdk and and dotnet-targeting-pack (from the official repos) require netstandard-targeting-pack (and not netstandrad-targeting-pack-2.1), and this is not provided, which creates a conflict. I didn't mean to remove the provides of netstandrad-targeting-pack-2.1, just to add the provides of netstandrad-targeting-pack.

Regardless, netstandard-targeting-pack-bin can be safely removed from conflicts and provides, as this is already the package name itself (and is not depended on by anybody).

The official package name is netstandard-targeting-pack, but it actually provides netstandard-targeting-pack-2.1.

This package provides netstandard-targeting-pack-2.1 and itself, so it's conflicting the package in the official repos as intended

I assume the conflicts and provides were meant to be netstandard-targeting-pack and not netstandard-targeting-pack-bin?

Cannot install this package because it gives target not found: dotnet-sdk-bin

The arm builds don't work at the moment because of the linux-x64 reference in package_dotnet-targeting-pack-bin. I've uploaded a fixed PKGBUILD here: https://pastebin.com/rMv3PAR5

Hello,

As a heads-up, the source-built community package switched to split targetting packs, in order to allow multiple SDK versions to be installed side-by-side.

Also, the dotnet.sh script file got removed and /usr/bin/dotent directly symlinks to /usr/share/dotnet/dotnet now.

It would be nice if you could switch to that new packaging logic, so it can be installed with other packages. You can check the community PKGBUILD, or my dotnet-core-preview PKGBUILD, to see the changes required.

Thanks in advance!

@CruciformHawk7 Sorry I forgot to reply.

When you mentioned pacaur I wanted to say that that is most likely the issue. I tried to use it in the past and it always had issues what the cmd tools don't have.

On the second issue, the sdk version is officially 3.1.202 so it's correct. On the download page you can see the versions, we are using {runtimever}.sdk{sdkver} otherwise it would be hard to keep track.

Hello, @Gr3q. I attempted upgrading the package then. It simply did not upgrade, so I tried uninstalling and reinstalling the package, when I received this error. pacaur doesn't seem to tell me what packages are in conflict. It simply says this: :: unresolvable package conflicts detected :: failed to prepare transaction (conflicting dependencies: dotnet-runtime-bin) I have been using the package without any issues earlier. I don't know what seems to be the issue here. As the pinned comment reads, I have installed dotnet-host-bin and is upto date. I don't seem to be facing issues there. I get issues when I attempt installing dotnet-runtime-bin, dotnet-sdk-bin, and aspnet-runtime-bin. Thank you.

Edit: using yay seemed to have fixed the issue, but the package downloads dotnet-sdk version 3.1.202. Is this intentional?

@CruciformHawk7 which packages do you install exactly?

Hello,

When I upgrade the package, I get failed to prepare transaction (conflicting dependencies: dotnet-runtime-bin). I have removed dotnet-* packages and the issue still persists.

I get it now, thanks

Isn't this is obvious? To let other packages know what these packages provide and for easy version comparison. Example: A package that only requires the dotnet runtime later or equals to 3, this can be easily be described with dotnet-runtime>=3 in the PKGBUILD. The official one is fine with this, but not with this package is not since it only provide dotnet-runtime-3.1 but not dotnet-runtime, so it can't be recognized and compared. Another example is a package that don't have this requirement, any version of dotnet runtime is fine.

I'm happy to add it to the array, but could you explain it to me what is the benefit of doing this?

The packages should add to their provide array with their corresponding version like: provides=('dotnet-sdk=3.1.1.sdk101'), or use with variable: provides=("dotnet-sdk=$pkgver") (the official ones don't need to do this because they are implicitly added with their package name and version)

IMPORTANT INSTALLATION INFO (a reminder for myself as well):

For dotnet to work you need to EXPLICITLY install:

• ONE dotnet-host - highest version possible
• ANY NUMBER of dotnet-runtimes (and its sdks after if you want to build as well - Right now version 'bin', '3.1', '3.0', '2.2' and '2.1' are tested to work together)

If you keep the install order in mind and you don't rely on pacman to resolve your dependencies you will be fine.

Longer explanation:

Every dotnet-sdk is dependent on a specific version of dotnet-runtime, this is built into dotnet.

Technically you only need the latest dotnet-sdk because it can build to any earlier versions.

Thank you again @Gr3q!

@riscie the community package will be updated as far as I know, it is in the works.

The purpose of this package was that I could use dotnet on armv7f architecture as well, what is missing from the repos.

Hey @Gr3q thank you so much for your work. It seems with the help of your effort we no have a way to use dotnet core 3.0 on arch. Does that mean the community packages of dotnet will no longer be updated? They were flagged out-of-date quite a while ago.

Edit: Tested, sdk is listed correctly.

All packages are part of this base, it should work correctly now.

let me know if its still not working.

@satcom886 Yeah I know, requested its deletion so I could put it up again as part of this package base

@Gr3q dotnet-runtime-bin seems to have been orphaned... Do you think you would be able to take ownership of that package and update it? If you have the time of course.

Thanks for your work!

Right now this package base is unusable at the moment, because it half-depends on dotnet-runtime-bin (what is out of date version 2.2.6).

I contacted the maintainer and that (hopefully) will be sorted tomorrow. After that is sorted, I will start fixing the issues with it.

Also there were some typos for the aarch64 architecture, so that did not work, that should be fixed now.

Also it seems to me like this is not working as intended... When I run dotnet --list-sdks, I get nothing.

Could you please add an arm64 version as well? It seems Microsofts has it: https://dotnet.microsoft.com/download/dotnet-core/3.0#sdk-3.0.100