.NET 6: The framework 'Microsoft.AspNetCore.App', version '5.0.0' was not found

I have the .NET 6 SDK installed on my Apple M1 laptop.

I have <TargetFramework>net5.0</TargetFramework> projects which I can successfully restore (dotnet restore) and successfully build (dotnet build) without any errors or warnings, but when I run dotnet run I get the following error on my ASP.NET 5 project:

It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '5.0.0' was not found.
  - The following frameworks were found:
      6.0.0-preview.1.21103.6 at [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
      6.0.0-preview.2.21154.6 at [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=5.0.0&arch=arm64&rid=osx.11.0-arm64

The URL in the error message doesn’t work and redirects me to the default .NET download page:

https://aka.ms/dotnet-core-applaunch?framework=Microsoft.AspNetCore.App&framework_version=5.0.0&arch=arm64&rid=osx.11.0-arm64

When I change my TargetFramework to 6.0 then I can run my app, but I don’t want to upgrade yet. I just want to develop on my new laptop and also it’s illogical to me that I can build the binaries but then not run them when targeting .NET 5.

[dasMulli]

Can you try setting

<PropertyGroup>
  <RollForward>Major</RollForward>
</PropertyGroup>

in the csproj so the emitted runtimeconfig.json tells the host to execute the 5.* app on a 6.* framework? Major version roll-forward currently requires explicit opt in.

[dasMulli]

but the final project can still be executed on the 6.0 runtime with the 5.0 assemblies loaded

This might have worked with the 1.* versions.

I like to explain it like this: You are always targeting a runtime + version (excluding runtime specifics for a moment). However, there are actually multiple runtimes and you usually target only one of them. Until 3.* you could even only target one of them. The runtime in your case is actually ASP.NET Core. For the App, it requests Microsoft.AspNetCore.App version 5.0.0 as a runtime. This is what the muxer looks for (and fails to find) on your local machine.

In theory, Microsoft.AspNetCore.App could ship with all dependencies needed to run a .NET App but in practice it internally depends on Microsoft.NETCore.App - but the host doesn’t know that until it reads /usr/local/shared/dotnet/shared/Microsoft.AspNetCore.App/5.0.4/Microsoft.AspNetCore.App.runtimeconfig.json for example which tells it to also load the other framework. (you could try copying one over from an x86 installation and change the file to reference a 6.0.0 framework just for fun, no guarantees)

In 3.* onwards you can also target multiple runtimes, e.g. Microsoft.AspNetCore.App and Microsoft.WindowsDesktop.App.

For 6.0 I guess this hidden complexity is going to get more interesting as there are new frameworks like Microsoft.iOS and Microsoft.Android. These may or may not depend on Microsoft.NETCore.App and contain Mono bits instead of CoreCLR. (I have no idea as of yet, but just want to show the possibilities of this system).