Package Details: dotnet-host-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: A generic driver for the .NET Core Command Line Interface (binary)
Upstream URL: https://www.microsoft.com/net/core
Keywords: .net dotnet microsoft
Licenses: MIT
Conflicts: dotnet-host
Provides: dotnet-host
Submitter: Gr3q
Maintainer: Gr3q (natep)
Last Packager: Gr3q
Votes: 43
Popularity: 1.60
First Submitted: 2019-10-02 17:13 (UTC)
Last Updated: 2024-11-13 09:45 (UTC)

Required by (33)

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 .. 3 4 5 6 7 8 9 10 Next › Last »

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: https://pastebin.com/rMv3PAR5

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

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!

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?

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