Package Details: dotnet-host-bin 6.0.5.sdk300-1

Git Clone URL: (read-only, click to copy)
Package Base: dotnet-core-bin
Description: A generic driver for the .NET Core Command Line Interface (binary)
Upstream URL:
Keywords: .net dotnet microsoft
Licenses: MIT
Conflicts: dotnet-host
Provides: dotnet-host
Submitter: Gr3q
Maintainer: Gr3q
Last Packager: Gr3q
Votes: 33
Popularity: 0.134072
First Submitted: 2019-10-02 17:13 (UTC)
Last Updated: 2022-05-12 20:01 (UTC)

Required by (27)

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

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?

vinnivitz commented on 2022-04-19 12:15 (UTC)

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

AkechiShiro commented on 2022-04-18 13:19 (UTC)

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 ?

Gr3q commented on 2022-01-28 09:25 (UTC) (edited on 2022-01-28 09:27 (UTC) by Gr3q)

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

sarvasana commented on 2022-01-27 22:20 (UTC) (edited on 2022-01-27 22:21 (UTC) by sarvasana)

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 script and never looked back again. Maybe these issues are still there, maybe not.

Will check this weekend.

Gr3q commented on 2022-01-26 20:44 (UTC)

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

sarvasana commented on 2021-12-16 12:26 (UTC) (edited on 2021-12-16 12:28 (UTC) by sarvasana)

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:

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.

Gr3q commented on 2021-12-15 08:52 (UTC)

@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

petep commented on 2021-12-15 00:47 (UTC) (edited on 2021-12-15 00:47 (UTC) by petep)

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


sarvasana commented on 2021-12-02 22:30 (UTC) (edited on 2021-12-02 22:35 (UTC) by sarvasana)

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

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

Gr3q commented on 2021-11-09 08:21 (UTC)

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

Sejsel commented on 2021-11-09 02:20 (UTC) (edited on 2021-11-09 02:20 (UTC) by Sejsel)

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.

amos commented on 2021-04-20 16:12 (UTC)

Cool, thanks! And thanks for maintaining this!

Gr3q commented on 2021-04-20 08:25 (UTC)

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

amos commented on 2021-04-19 14:04 (UTC)

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

SilentStoat commented on 2021-03-21 23:17 (UTC)

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.

Gr3q commented on 2021-03-12 08:15 (UTC)

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

satcom886 commented on 2021-03-11 20:20 (UTC) (edited on 2021-03-11 20:21 (UTC) by satcom886)

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

servimo commented on 2021-03-11 19:00 (UTC) (edited on 2021-03-11 19:01 (UTC) by servimo)

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?

Gr3q commented on 2021-03-11 08:23 (UTC)

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)

satcom886 commented on 2021-03-11 08:13 (UTC)

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.

satcom886 commented on 2021-03-11 08:09 (UTC)

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

Gr3q commented on 2021-03-11 07:55 (UTC)

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.

amos commented on 2021-03-10 12:39 (UTC)

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

Gr3q commented on 2021-03-10 07:43 (UTC)

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

amos commented on 2021-03-09 19:32 (UTC)

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

Alkaris commented on 2021-02-04 19:28 (UTC)

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

patstew commented on 2020-09-10 22:03 (UTC)

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:

fmauNeko commented on 2020-07-31 11:49 (UTC)


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

Gr3q commented on 2020-05-20 09:26 (UTC) (edited on 2020-05-20 09:26 (UTC) by Gr3q)

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

CruciformHawk7 commented on 2020-05-18 04:39 (UTC) (edited on 2020-05-18 04:53 (UTC) by CruciformHawk7)

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?

Gr3q commented on 2020-05-16 16:35 (UTC)

@CruciformHawk7 which packages do you install exactly?

CruciformHawk7 commented on 2020-05-16 15:35 (UTC)


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.

Gr3q commented on 2020-01-16 09:41 (UTC)

I get it now, thanks

huupoke12 commented on 2020-01-16 09:39 (UTC)

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.

Gr3q commented on 2020-01-16 09:15 (UTC)

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

huupoke12 commented on 2020-01-16 08:46 (UTC) (edited on 2020-01-16 08:48 (UTC) by huupoke12)

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)

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.

riscie commented on 2019-10-04 14:18 (UTC)

Thank you again @Gr3q!

Gr3q commented on 2019-10-04 12:01 (UTC)

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

riscie commented on 2019-10-04 09:09 (UTC)

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.

Gr3q commented on 2019-10-03 21:59 (UTC) (edited on 2019-10-04 07:43 (UTC) by Gr3q)

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.

Gr3q commented on 2019-10-03 16:36 (UTC)

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

satcom886 commented on 2019-10-03 14:53 (UTC)

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

satcom886 commented on 2019-10-03 09:24 (UTC)

Thanks for your work!

Gr3q commented on 2019-10-02 19:52 (UTC) (edited on 2019-10-03 16:35 (UTC) by Gr3q)

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.

satcom886 commented on 2019-10-02 19:27 (UTC)

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

satcom886 commented on 2019-10-02 19:05 (UTC)

Could you please add an arm64 version as well? It seems Microsofts has it: