M1 Mac cannot find libhostfxr.dylib

[abist]

Describe the bug

I'm trying to port an app from .NET 5 to .NET 6 to support M1 Macs. I could build and publish the project fine, but when I start the app, I get the following error -

Failed to load 
 azuredatastudio/extensions/mssql/sqltoolsservice/OSX/3.0.0-release.129/libhostfxr.dylib, error: dlopen(azuredatastudio/extensions/mssql/sqltoolsservice/OSX/3.0.0-release.129/libhostfxr.dylib, 1): no suitable image found.  Did find:
 azuredatastudio/extensions/mssql/sqltoolsservice/OSX/3.0.0-release.129/libhostfxr.dylib: mach-o, but wrong architecture
 azuredatastudio/extensions/mssql/sqltoolsservice/OSX/3.0.0-release.129/libhostfxr.dylib: mach-o, but wrong architecture
The library libhostfxr.dylib was found, but loading it from 
 azuredatastudio/extensions/mssql/sqltoolsservice/OSX/3.0.0-release.129/libhostfxr.dylib failed
  - Installing .NET prerequisites might help resolve this problem.
     https://go.microsoft.com/fwlink/?linkid=2063366

I saw other similar issues, where this issue occurs when loading .NET 5 and 6 side by side, but I only have .NET 6 on this M1 machine.

To Reproduce

Exceptions (if any)

Further technical details

• Include the output of dotnet --info

 .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:  11.6
 OS Platform: Darwin
 RID:         osx.11.0-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]

To install additional .NET runtimes or SDKs:
  https://aka.ms/dotnet-download

• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version - VS Code for Mac (ARM64) - Big Sur 11.6
• Result of running dotnet --list-sdks - 6.0.100-rc.1.21458.32 [/usr/local/share/dotnet/sdk]

[marcpopMSFT]

I recommend trying this again once RC2 is available as we've made significant changes to our Mac installer behavior. CC @vitek-karas @ericstj to see if they agree that our rc2 changes will fix this.

[vitek-karas]

Is azuredatastudio/extensions/mssql/sqltoolsservice/OSX/3.0.0-release.129/ path to your built app? (it's hard to tell)
Do you publish the app as self-contained or not?
What do you publish the app for (RID)?

[abist]

That's the path of our backend that uses dotnet in the main app.
We use dotnet to build this project - https://github.com/Microsoft/sqltoolsservice, which is the backend for this app - https://github.com/microsoft/azuredatastudio. And yes, it's a self contained app.

[vitek-karas]

I assume in your try you changed the TFM to net6.0 on everything, mainly the main app (entry point).
When you publish, what RID do you publish for?
How do you start the app? (using the executable, or do you use dotnet app.dll approach)

Did you install any other .NET runtime/SDK on your machine (other than .NET 6 osx-arm64)?

[mrlife]

I am running into this error as well on a 6.0.2 version of dotnet-ef. I have the ARM64 version of the SDK installed (never installed the x64 version). It's not a self-contained or framework-dependent app.

I do see libhostfxr.dylib in the following location, but it seems it is not looking there:

/usr/local/share/dotnet/host/fxr/6.0.2/libhostfxr.dylib

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/user1/.dotnet/tools/.store/dotnet-ef/6.0.2/dotnet-ef/6.0.2/tools/netcoreapp3.1/any/].
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].

The .NET runtime can be found at:

• https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=osx.12-x64&apphost_version=6.0.2

.NET SDK (reflecting any global.json):
 Version:   6.0.200
 Commit:    4c30de7899

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  12.2
 OS Platform: Darwin
 RID:         osx.12-arm64
 Base Path:   /usr/local/share/dotnet/sdk/6.0.200/

Host (useful for support):
  Version: 6.0.2
  Commit:  839cdfb0ec

.NET SDKs installed:
  6.0.101 [/usr/local/share/dotnet/sdk]
  6.0.200 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 6.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Edit: looks like there is a workaround here: dotnet/efcore#25927. I went with the second one " Installing dotnet ef locally".

[vitek-karas]

@mrlife - the workaround to install dotnet ef locally works, but I don't think the linked EF issue is the same problem. The linked issue was fixed (the globally installed ef apphost was not signed and thus it failed to run at all). The issue you're seeing is something else - the tool runs, but it fails to find hostfxr.

Based on the error message, this is looking for x64 runtime. Which means the process which triggered this error started as x64 process. So the question is, which process is this? And how come it's x64 if all you installed is arm64.

What is the command you're trying to run which fails?
Can you grab a host trace? (export COREHOST_TRACE=1, export COREHOST_TRACEFILE=host.txt, ... repro, host.txt is the trace). Please note that the trace will contain information about your machine, local file paths, env. variables and so on - so only share it if you're OK with sharing such information.

[mrlife]

Hi @vitek-karas, thank you for putting it in perspective. The command I was running is dotnet ef migrations add migration21.

[vitek-karas]

Thanks @mrlife. Just to check what the problem is, try to run the command using the following:
dotnet /Users/user1/.dotnet/tools/.store/dotnet-ef/6.0.2/dotnet-ef/6.0.2/tools/netcoreapp3.1/any/dotnet-ef.dll (I think it should be there, but not 100% sure). - I would expect this to work.
/Users/user1/.dotnet/tools/dotnet-ef - I would expect this to fail. If this does indeed fail, can you check what is the target architecture of this executable?

@agocke @VSadov could one of you try to repro this on M1 hardware?

[mrlife]

@vitek-karas Ok, yes the first one runs fine. The second one throws the same libhostfxr.dylib error from my first post.

I get x86_64 for the architecture, though as noted, this was a new laptop and I only installed the ARM64 SDK.

lipo -info /Users/user1/.dotnet/tools/dotnet-ef
Non-fat file: /Users/user1/.dotnet/tools/dotnet-ef is architecture: x86_64

Edit: this is what I used to install the dotnet tool globally

dotnet tool install --global dotnet-ef

[vitek-karas]

@mrlife can you please try one other thing:

• uninstall the dotnet-ef global tool (something like dotnet tool uninstall dotnet-ef)
• make sure that the dotnet-ef executable which was x86_64 is removed - if not please delete it
• install dotnet-ef global tool again, so dotnet tool install dotnet-ef

I want to make sure that the executable was created by the tool install process. If it's still broken after this, it should be easier for us to determine where it's broken.

[mrlife]

@vitek-karas I uninstalled both the local and global dotnet-ef, verified they were uninstalled, then reinstalled the global one with:

dotnet tool install dotnet-ef --global

Checking the architecture for /Users/user1/.dotnet/tools/dotnet-ef shows that the x86_64 version was installed with this command.

[vitek-karas]

Maybe try adding '-a arm64' to the install command...

[mrlife]

Awesome, this works. Would this be the official way or do you think the tool installer will be updated to detect the architecture?

dotnet tool install dotnet-ef --global -a arm64

[vitek-karas]

I think this is a bug in the tool installer. Would you mind creating a new issue (it's more authentic if it comes from external user 😉). I can fill in the details on it later on. Simply put, dotnet install -g dotnet-ef followed by dotnet ef must work and it currently doesn't seem to work.

[mrlife]

Ok, all set. Thanks for working on this with me.

[WuJieFly]

@vitek-karas I uninstalled both the local and global dotnet-ef, verified they were uninstalled, then reinstalled the global one with:

dotnet tool install dotnet-ef --global

Checking the architecture for /Users/user1/.dotnet/tools/dotnet-ef shows that the x86_64 version was installed with this command.
thanks

[MhdHawa]

vitek-karas. Thank you man for your effort and support I had the same issue and because of you the issue resolved.

[ekkaiasmith]

Hi, I'm on MacBook Air M2. I have the following issue while trying to execute a F# project:

Failed to load /opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib, error: dlopen(/opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib, 0x0001): tried: '/opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64')), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib' (no such file), '/opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib' (mach-o file, but is an incompatible architecture (have 'arm64', need 'x86_64'))
The library libhostfxr.dylib was found, but loading it from /opt/homebrew/Cellar/dotnet/8.0.1/libexec/host/fxr/8.0.1/libhostfxr.dylib failed
  - Installing .NET prerequisites might help resolve this problem.

[harish-venkataramanan-cko]

@ekkaiasmith were you able to fix the issue

[ekkaiasmith]

@ekkaiasmith were you able to fix the issue

Not really. I decided to install F# in a Docker container and it works perfectly. This article explains how to configure the Dockerfile: https://hamy.xyz/labs/2022-10-run-fsharp-dotnet-in-docker-console-app