Package Details: dotnet-sdk-bin 3.1.9.sdk403-1

Git Clone URL: (read-only, click to copy)
Package Base: dotnet-core-bin
Description: The .NET Core SDK (binary)
Upstream URL:
Licenses: MIT
Conflicts: dotnet-sdk=3.1.9.sdk403, dotnet-sdk-3.1, dotnet-sdk-bin
Provides: dotnet-sdk=3.1.9.sdk403, dotnet-sdk-3.1, dotnet-sdk-bin
Submitter: Gr3q
Maintainer: Gr3q
Last Packager: Gr3q
Votes: 13
Popularity: 0.26
First Submitted: 2019-10-02 17:13
Last Updated: 2020-10-14 21:04

Dependencies (2)

Required by (43)

Sources (3)

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' and '2.1' is 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

1 2 3 Next › Last »

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.

Gr3q commented on 2020-01-16 09:15

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

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)