runtime: Running a .NET 5 project on macOS M1 with .NET 6 leads to confusing error message

Steps to reproduce:

Install .NET 6 RC1 on an M1 Mac with the ARM64 architecture. Make sure there are no previous installs of .NET.

.NET SDK (reflecting any global.json):
Version:   6.0.100-rc.1.21458.32
Commit:    d7c22323c4

Runtime Environment:
OS Name:     Mac OS X
OS Version:  12.0
OS Platform: Darwin
RID:         osx-arm64
Base Path:   /usr/local/share/dotnet/sdk/6.0.100-rc.1.21458.32/

Host (useful for support):
  Version: 6.0.0-rc.1.21451.13
  Commit:  d7619cd4b1

.NET SDKs installed:
  6.0.100-rc.1.21458.32 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.0-rc.1.21452.15 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.0-rc.1.21451.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Try to run a .NET application that targets .NET 5 with dotnet run You’ll get output that looks like:

Failed to load /usr/local/share/dotnet/host/fxr/6.0.0-rc.1.21451.13/libhostfxr.dylib, error: dlopen(/usr/local/share/dotnet/host/fxr/6.0.0-rc.1.21451.13/libhostfxr.dylib, 0x0001): tried: '/usr/local/share/dotnet/host/fxr/6.0.0-rc.1.21451.13/libhostfxr.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/usr/local/lib/libhostfxr.dylib' (no such file), '/usr/lib/libhostfxr.dylib' (no such file)
The library libhostfxr.dylib was found, but loading it from /usr/local/share/dotnet/host/fxr/6.0.0-rc.1.21451.13/libhostfxr.dylib failed
  - Installing .NET prerequisites might help resolve this problem.
    https://go.microsoft.com/fwlink/?linkid=2063366

I would expect to see a better error message, either indicating that .NET 5 is not installed, or that an available SDK/runtime is not available.

Interestingly enough, even with a rollForward policy of major, it still fails with the same error message.

global.json:

{
    "sdk": {
      "allowPrerelease": true,
      "rollForward": "major"
    }
  }

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 62 (40 by maintainers)

Most upvoted comments

Ugh, got my x64 and arm64 copy screwed up again. I get a slightly different, but still not great error message, because I have /etc/dotnet/install_location set up for how it should be after the installer is fixed (pointing to an empty x64 subdirectory).

My error message is:

$ dotnet run
A fatal error occurred. The required library libhostfxr.dylib could not be found.
If this is a self-contained application, that library should exist in [/Users/angocke/tmp/net5/bin/Debug/net5.0/].
If this is a framework-dependent application, install the runtime in the global location [/usr/local/share/dotnet/x64] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [/etc/dotnet/install_location].

The .NET runtime can be found at:
  - https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=osx.11.0-x64&apphost_version=5.0.10

Unfortunately this is still very misleading.

agocke on Sep 16, 2021

Does just plain “dotnet build” succeed without problems?

@agocke It does. The exact project I am using is here: https://gist.github.com/vcsjones/1fef26b5a9ad4bfe934425b272d56797

dotnet build succeeds. dotnet run fails.

The dotnet --info output is the same as in the initial issue comment.

vcsjones on Sep 15, 2021

@vitek-karas After I have redone the whole installation steps again and found what works and what doesn’t. Below is what I did to make it mostly work.

Installed SDK 3.1.408 Works well with netcoreapp3.1
Installed SDK 5.0.402 Works well with netcoreapp3.1 and net5.0
System works well with 3.1 and 5.0 and this is what I had before attempting 6.0 installation two months ago.
Installed SDK 6.0.10 dotnet --info still shows all three versions of SDKs and Runtimes 3.1 and 5.0 stopped working. SDK 3.1.408 and SDK 5.0.402 were wiped up from /usr/local/share/dotent /usr/local/share/dotent/x64 folder doesn’t exist
Installed SDK 3.1.415 and SDK 5.0.403 (per Microsoft)
/usr/local/share/dotent/x64 folder showed up. SDK 3.1.415 and SDK 5.0.403 appeared in x64 folder dotnet created by SDK 6.0.10 got wiped up and disappeared from /usr/local/share/dotnet
Reinstalled SDK 6.0.10
dotnet appeared in /usr/local/share/dotnet
dotnet --info shows SDK 3.1.408 Rtm 3.1.14 SDK 5.0.402 Rtm 5.0.11 These are older versions I installed (Steps 1 & 2) but got wiped up during 6.0 installation
System.Runtime.InteropServices.RuntimeInformation.FrameworkDescription captures different runtimes: Rtm 3.1.21 and Rtm 5.0.12 I installed these after 6.0 installation wiped up my previous SDK/Runtime
dotnet run works well with netcoreapp3.1, net5.0, net6.0
dotnet publish works well with netcoreapp3.1, net5.0, net6.0
dotnet {appname}.dll works well with net6.0
dotnet {appname}.dll does NOT work with netcoreapp3.1 or net5.0
/usr/local/share/dotnet/x64/dotnet {appname}.dll works with netcoreapp3.1 or net5.0

The tricky parts are misleading dotnet --info and Step 15. Otherwise, this setting works for me. Happy new year.

david-d-an on Jan 1, 2022

@vcsjones Is there a reason you decided to enable roll-forward rather than switching to net6.0 TFM? Or installing the net5.0 runtime?

I just bumped the TFM but I will admit I wasted a bit of time getting detoured by this. I don’t really expect it to work now that I understand what is happening, but it took a while to get there. I only called out rollForward because I would expect that to work. Why would it load the .NET 5 AppHost if I should be rolling forward to 6? (Keep in mind I have a very naive understanding with how this works).

Here are the events that led to this:

“Kevin, please run this .NET repo”
Okay, let me clone this repository, and dotnet run it
Sees:

but is an incompatible architecture (have ‘arm64’, need ‘x86_64’))
Oh wow, something must be broken with my installation. Let’s go down a technical rabbit hole of inspecting libraries with otool -vh instead of looking at more obvious things.
I don’t know. Let’s re-install?
There is nothing at the bottom of this rabbit hole. Let’s try something else.
Let’s try on a brand new .NET app with dotnet new
Weird. That worked. What’s the difference?
Oh. dotnet new made the project with a .NET 6 TFM. Is that it?
It was the TFM.
… I wonder if roll forward will fix it?
It does not.
Let’s write an issue.

My hope is that at least this error path can have better output for folks.

vcsjones on Sep 16, 2021

Here are the “instructions” on how to configure your machine today.

https://github.com/dotnet/sdk/issues/20584

richlander on Sep 15, 2021