Package Base Details: dotnet-core-bin

Git Clone URL: (read-only, click to copy)
Submitter: Gr3q
Maintainer: Gr3q
Last Packager: Gr3q
Votes: 28
Popularity: 3.46
First Submitted: 2019-10-02 17:13
Last Updated: 2021-04-06 17:32

Pinned Comments

Gr3q commented on 2019-10-05 07:28

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 Next › Last »

amos commented on 2021-03-09 19:32

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

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

patstew commented on 2020-09-10 22:03

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


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

@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

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

@CruciformHawk7 which packages do you install exactly?

CruciformHawk7 commented on 2020-05-16 15:35


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

I get it now, thanks

huupoke12 commented on 2020-01-16 09:39

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.