Package Details: aspnet-runtime-8.0-bin 8.0.23.sdk417-1

Git Clone URL: https://aur.archlinux.org/dotnet-core-8.0-bin.git (read-only, click to copy)
Package Base: dotnet-core-8.0-bin
Description: The ASP.NET Core runtime (binary)
Upstream URL: https://www.microsoft.com/net/core
Licenses: MIT
Conflicts: aspnet-runtime-8.0
Provides: aspnet-runtime-8.0
Submitter: Gr3q
Maintainer: Gr3q
Last Packager: Gr3q
Votes: 3
Popularity: 0.024111
First Submitted: 2024-11-13 09:52 (UTC)
Last Updated: 2026-01-15 09:34 (UTC)

Dependencies (1)

Required by (16)

Sources (3)

Latest Comments

Gr3q commented on 2025-11-22 19:44 (UTC) (edited on 2025-11-22 19:44 (UTC) by Gr3q)

@vitaliikuzhdin I see what you mean now. When I started there were no multiple versions of runtimes in the official repos (tbh the official packages didn't actually exist) and people were specifying the version in their dependencies instead.

That did change in the recent year(s) but these packages still don't reflect that. I will make the changes tomorrow.

vitaliikuzhdin commented on 2025-11-22 16:07 (UTC)

@Gr3q, ah, I just noticed you started removing those provides entries on the dotnet-core-bin packages. However, those are correct for the unversioned -bin package and should be brought back. I was only referring to the versioned packages (dotnet-core-x.x*).

vitaliikuzhdin commented on 2025-11-22 16:00 (UTC)

@Gr3q,

I'm not sure what you mean, what exactly is the problem with this package?

You need to remove provides=("dotnet-runtime=${_runtimever}") and similar, because these are incorrect. To provide an up-to-date package means to be a drop-in replacement of the same version, otherwise, errors can occur like the one described above.

You don't even have it installed.

That's false. And how is that even related? Do I need to install packages with incorrect provides to know they have incorrect provides? Or can I simply read the PKGBUILD?

Gr3q commented on 2025-11-22 09:11 (UTC) (edited on 2025-11-22 09:11 (UTC) by Gr3q)

@vitaliikuzhdin I'm not sure what you mean, what exactly is the problem with this package? You don't even have it installed. This package provides dotnet-*-8.0 packages and their exact versions (the thing that actually differs from the official packages in the provides section)

vitaliikuzhdin commented on 2025-11-21 16:56 (UTC) (edited on 2025-11-21 16:56 (UTC) by vitaliikuzhdin)

@Gr3q, so at least the runtime packages shouldn’t have the provides. As for the SDK, it can indeed target older .NET releases for the build, but not for many other functions. For example, running dotnet restore fails if the version is mismatched:

The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application 'restore' does not exist.
  * You intended to execute a .NET SDK command:
      A compatible .NET SDK was not found.

Requested SDK version: 8.0.405
global.json file: (...)/global.json

Installed SDKs:
9.0.306 [/usr/share/dotnet/sdk]

Install the [8.0.405] .NET SDK or update [(...)/global.json] to match an installed SDK.

Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found

Arch packages that claim to provide another package should be drop-in replacements for what they are providing, which is clearly not the case here. I guess this is also the reason the official versioned .NET packages do not have provides. I don’t think deviating from the official packages is a great choice.

Gr3q commented on 2025-11-16 19:26 (UTC)

@vitaliikuzhdin I went by this: https://learn.microsoft.com/en-us/dotnet/core/versions/selection#target-framework-monikers-define-build-time-apis

Specific versions of runtimes will be needed to run apps targeting those versions, but in theory when building you can target earlier versions of runtimes with the latest SDK. I'm not sure how far you can target things back though.

vitaliikuzhdin commented on 2025-11-15 23:48 (UTC)

Is there a reason your versioned .NET packages claim to provide their newer counterparts? For example, if I try to build a 8.0 project using the 9.0 SDK, it fails, and the same applies when running projects that depend on an older runtime with a newer runtime. The official source-built packages don’t provide this either. Or am I missing something?