Package Details: dotnet-runtime-bin 9.0.0.sdk100-1

Git Clone URL: https://aur.archlinux.org/dotnet-core-bin.git (read-only, click to copy)
Package Base: dotnet-core-bin
Description: The .NET Core runtime (binary)
Upstream URL: https://www.microsoft.com/net/core
Keywords: .net dotnet microsoft
Licenses: MIT
Conflicts: dotnet-runtime, dotnet-runtime-9.0
Provides: dotnet-runtime, dotnet-runtime-9.0
Submitter: Gr3q
Maintainer: Gr3q
Last Packager: Gr3q
Votes: 45
Popularity: 2.42
First Submitted: 2019-10-02 17:13 (UTC)
Last Updated: 2024-11-13 09:45 (UTC)

Required by (103)

Sources (4)

Pinned Comments

Gr3q commented on 2019-10-05 07:28 (UTC) (edited on 2021-02-13 09:06 (UTC) by Gr3q)

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.

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 Next › Last »

crimson commented on 2022-06-18 17:07 (UTC)

@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

jongeduard commented on 2022-06-18 15:40 (UTC) (edited on 2022-06-18 15:45 (UTC) by jongeduard)

@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?

crimson commented on 2022-06-18 10:54 (UTC) (edited on 2022-06-19 09:12 (UTC) by crimson)

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

jongeduard commented on 2022-05-30 21:13 (UTC) (edited on 2022-05-30 21:15 (UTC) by jongeduard)

@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!

Gr3q commented on 2022-05-30 08:25 (UTC)

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

jongeduard commented on 2022-05-29 22:32 (UTC)

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

Gr3q commented on 2022-05-29 17:32 (UTC)

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

jongeduard commented on 2022-05-27 19:18 (UTC) (edited on 2022-05-29 12:10 (UTC) by jongeduard)

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.

vinnivitz commented on 2022-04-22 12:39 (UTC)

@sarvasana Thank you. This version worked!

sarvasana commented on 2022-04-19 12:18 (UTC)

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

« First ‹ Previous 1 2 3 4 5 6 7 8 9 10 Next › Last »