Package Details: dotnet-runtime-bin 6.0.1.sdk101-4

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=6.0.1, dotnet-runtime-6.0
Provides: dotnet-runtime=6.0.1, dotnet-runtime-6.0
Submitter: Gr3q
Maintainer: Gr3q
Last Packager: Gr3q
Votes: 33
Popularity: 1.43
First Submitted: 2019-10-02 17:13
Last Updated: 2021-12-15 08:38

Required by (61)

Sources (4)

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

1 2 3 4 5 Next › Last »

Gr3q commented on 2022-01-28 09:25

@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

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 dotnet-install.sh 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

@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

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: https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script#script-behavior

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

@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

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 dotnet-install.sh 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.

See https://github.com/dotnet/SqlClient/issues/1427

sarvasana commented on 2021-12-02 22:30

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

https://docs.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script

curl -sSL https://dot.net/v1/dotnet-install.sh | 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

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

Sejsel commented on 2021-11-09 02:20

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

Cool, thanks! And thanks for maintaining this!