dotnet-ef needs to target 6

[tylermichael]

I'm trying to get x64 and amd64 to play nicely together on my machine.

I've followed the steps here and so far things seem to be ok for normal usage.

However, when I run this I get:

> dnx64 ef --help
Failed to load /usr/local/share/dotnet/x64/host/fxr/5.0.10/libhostfxr.dylib, error: dlopen(/usr/local/share/dotnet/x64/host/fxr/5.0.10/libhostfxr.dylib, 1): no suitable image found.  Did find:
	/usr/local/share/dotnet/x64/host/fxr/5.0.10/libhostfxr.dylib: mach-o, but wrong architecture
	/usr/local/share/dotnet/x64/host/fxr/5.0.10/libhostfxr.dylib: mach-o, but wrong architecture
The library libhostfxr.dylib was found, but loading it from /usr/local/share/dotnet/x64/host/fxr/5.0.10/libhostfxr.dylib failed
  - Installing .NET prerequisites might help resolve this problem.
     https://go.microsoft.com/fwlink/?linkid=2063366

dnx64 is alias dnx64="/usr/local/share/dotnet/x64/dotnet"

I installed the ef tool with dotnet 6 arm64 version.

> file ~/.dotnet/tools/dotnet-ef
/Users/username/.dotnet/tools/dotnet-ef: Mach-O 64-bit executable arm64

The dotnet-ef binary is arm64 but I'm trying to execute it with my x64 dotnet install.

Any ideas how I can get this to work?

[ericstj]

cc @richlander @vitek-karas @agocke

Looks to me like this is using 5.0 bits not 6.0. I believe that's not supported you need to use 6.0 for macos ARM64. The 6.0 host is aware of architecture-specific runtime locations. Pre-6.0 host is not (since we didn't have an ARM64 6.0 installer.

[agocke]

This is a question for the tool install folks @marcpopMSFT @wli3 @joeloff -- what happens if a tool is installed using the ARM64 version but then tries to run using x64? Presumably using the x64 apphost will not work.

[joeloff]

Yes, it shouldn't. Emulation for x64 is supported on arm64, but arm64 on x64 is not supported AFAIK. Wouldn't tools mostly be MSIL instead of native code?

[vitek-karas]

I think this is about DOTNET_ROOT. SDK typically sets DOTNET_ROOT for its child processes, so that they run on the same runtime as the SDK itself. But that won't work for different architectures. This would be fixed by setting the DOTNET_ROOT_X64 in the SDK (as the arm64 apphost would ignore it). But that only works on 6.0 everything.

[agocke]

I believe dotnet tool install creates an apphost, but I don't know the exact circumstances or why it does so -- the design probably needs to be updated to account for this.

At the moment I'm not even sure this scenario should work -- should dotnet tools be shared across architecture or should they be separately installed?

[tylermichael]

Forgot to mention, the x64 version info is:

> dnx64 --info
.NET SDK (reflecting any global.json):
 Version:   5.0.401
 Commit:    4bef5f3dbf

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  11.0
 OS Platform: Darwin
 RID:         osx.11.0-x64
 Base Path:   /usr/local/share/dotnet/x64/sdk/5.0.401/

Host (useful for support):
  Version: 5.0.10
  Commit:  e1825b4928

.NET SDKs installed:
  5.0.401 [/usr/local/share/dotnet/x64/sdk]

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

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

[wli3]

This is a question for the tool install folks @marcpopMSFT @wli3 @joeloff -- what happens if a tool is installed using the ARM64 version but then tries to run using x64? Presumably using the x64 apphost will not work.

There is a whole design from Rich and it is implmeneted. Let me find the reference

[wli3]

dotnet/sdk#18889
and
dotnet/sdk#18832

[richlander]

Thanks @wli3.

There are multiple parts here:

• Pre .NET 6 SDKs are not supported on Apple Silicon. Update x64 emulation plan designs#249
• dotnet install does not create signed apphost on macOS Arm64 sdk#21349
• dotnet tool install -a arm64 fails sdk#21395

[agocke]

I guess this still doesn't quite answer the question for me -- right now if you take two zip files of the runtime and extract them separately and do dotnet tool install with one, is it expected that the tool will be usable from another?

This isn't really an architecture question, just a question about the scope of dotnet tool install.

[wli3]

dotnet tool install with one

The current behavior is, dotnet tool install is run on SDK, if installed without -a option. SDK would install the architecture itself is on (unless lower than 6.0). Therefor it cannot be run on the other runtime. I would defer @richlander @joeloff for what's the right behavior. However, considering we cannot make an apphost to run against both architectures, I don't think we can improve the user experience.

[marcpopMSFT]

So back to the original bug, if the customer had used the 6.0 sdk and specified -a to target x64 during install, at that point they can use the x64 emulated install to run the tool. Leaving open as discussion is still ongoing but it's not clear that there is a 6.0 bug.

[agocke]

I agree -- it's not clear to me there is a bug here, as installing in ARM64 and running in x64 doesn't necessarily seem to be a supported scenario.

[richlander]

I just tried this on RC2. Looks good.

You will see an error message, but that's because I don't have the right runtime installed. The key thing is that it see that the app is .NET 5 and creates an x64 host. That's the desired behavior.

rich@MacBook-Air-M1-2020 app % dotnet tool install -g dotnet-serve
You can invoke the tool using the following command: dotnet-serve
Tool 'dotnet-serve' (version '1.9.71') was successfully installed.
rich@MacBook-Air-M1-2020 app % dotnet-serve
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '5.0.0' (x64) was not found.
  - The following frameworks were found:
      3.1.19 at [/usr/local/share/dotnet/x64/shared/Microsoft.AspNetCore.App]
      6.0.0-rc.2.21470.37 at [/usr/local/share/dotnet/x64/shared/Microsoft.AspNetCore.App]
      6.0.0-rc.2.21475.12 at [/usr/local/share/dotnet/x64/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=x64&rid=osx.11.1-x64

I can also coerce the tool to run on Arm64:

rich@MacBook-Air-M1-2020 app % dotnet tool install -g dotnet-serve -a arm64
Skip NuGet package signing validation. NuGet signing validation is not available on Linux or macOS https://aka.ms/workloadskippackagevalidation .
You can invoke the tool using the following command: dotnet-serve
Tool 'dotnet-serve' (version '1.9.71') was successfully installed.
rich@MacBook-Air-M1-2020 app % dotnet-serve 
zsh: killed     dotnet-serve
rich@MacBook-Air-M1-2020 app % codesign -s - ~/.dotnet/tools/dotnet-serve 
rich@MacBook-Air-M1-2020 app % dotnet-serve                              
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '5.0.0' (arm64) was not found.
  - The following frameworks were found:
      6.0.0-rc.2.21470.37 at [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
      6.0.0-rc.2.21475.12 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.1-arm64
rich@MacBook-Air-M1-2020 app % export DOTNET_ROLL_FORWARD=LatestMajor
rich@MacBook-Air-M1-2020 app % dotnet-serve                          
Starting server, serving .
Listening on:
  http://localhost:52868

Press CTRL+C to exit
^C%                         

Minus the codesign issue, LGTM.

I think we can close the issue as a result. Yes?

/cc @sfoslund

[vitek-karas]

To the original issue in this thread:
dotnet ef ends up starting a new process by executing the ~/.dotnet/tools/dotnet-ef executable.
This is I think the correct behavior as it means it should not matter for architecture the dotnet is in the dotnet ef command, and the dotnet-ef executable should pick the right runtime based on the configuration.

This doesn't explain the failure though - the dotnet-ef is obviously arm64 (that's why there's the arch mismatch), but something is forcing it to try to run on x64 install location.

@tylermichael

• Could you please check what is the contents of the /etc/dotnet/install_location? And if there are files like /etc/dotnet/install_location_arm64 as well.
• In the repro, do you have DOTNET_ROOT (or potentially DOTNET_ROOT_ARM64) env. variable defined?

You can also try:

export COREHOST_TRACE=1
export COREHOST_TRACEFILE=host.txt
dnx64 ef
export COREHOST_TRACE=0

The produces host.txt contains local paths and env. variables, so please make sure you're OK with sharing it. This file should tell us exactly why the dotnet-ef was trying to load x64 runtime.

[tylermichael]

To add some context to my use case...

I have a 'Company.DbContexts' project that targets net5.0. I would like to have dotnet 5 and dotnet 6 (arm64) installed side by side to use them both for different projects.

When running dnx64 ef --help in that project, I didn't realize at the time that I had DOTNET_ROOT=/usr/local/share/dotnet/x64 set while using the arm64 ef binary.

➜  Company.DbContexts git:(develop) ✗ file ~/.dotnet/tools/dotnet-ef
/Users/username/.dotnet/tools/dotnet-ef: Mach-O 64-bit executable arm64
➜  Company.DbContexts git:(develop) ✗ export DOTNET_ROOT=/usr/local/share/dotnet/x64
➜  Company.DbContexts git:(develop) ✗ dnx64 ef --help
Failed to load /usr/local/share/dotnet/x64/host/fxr/5.0.10/libhostfxr.dylib, error: dlopen(/usr/local/share/dotnet/x64/host/fxr/5.0.10/libhostfxr.dylib, 1): no suitable image found.  Did find:
	/usr/local/share/dotnet/x64/host/fxr/5.0.10/libhostfxr.dylib: mach-o, but wrong architecture
	/usr/local/share/dotnet/x64/host/fxr/5.0.10/libhostfxr.dylib: mach-o, but wrong architecture
The library libhostfxr.dylib was found, but loading it from /usr/local/share/dotnet/x64/host/fxr/5.0.10/libhostfxr.dylib failed
  - Installing .NET prerequisites might help resolve this problem.
     https://go.microsoft.com/fwlink/?linkid=2063366

➜  Company.DbContexts git:(develop) ✗ unset DOTNET_ROOT
➜  Company.DbContexts git:(develop) ✗ dnx64 ef --help
Entity Framework Core .NET Command-line Tools 5.0.10

Usage: dotnet ef [options] [command]

Options:
  --version        Show version information
  -h|--help        Show help information
  -v|--verbose     Show verbose output.
  --no-color       Don't colorize output.
  --prefix-output  Prefix output with level.

Commands:
  database    Commands to manage the database.
  dbcontext   Commands to manage DbContext types.
  migrations  Commands to manage migrations.

Use "dotnet ef [command] --help" for more information about a command.

Seems like arm64 ef is trying to load x64 files and then dies because of the arch mismatch. Makes sense.

---

Continuing from the above setup,

➜  Company.DbContexts git:(develop) ✗ dnx64 ef database update --context MgxContext
Build started...
Build succeeded.
It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '5.0.0' (arm64) was not found.
  - The following frameworks were found:
      6.0.0-preview.2.21154.6 at [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
      6.0.0-rc.1.21451.13 at [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
      6.0.0-rc.2.21470.23 at [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

Now it seems the issue is it is unable to find my x64 5.0 install. I think that makes sense? Because ef is arm64 it makes sense that it's not able to utilize the x64 stuff?

If I reinstall with dotnet tool install -a x64 --global dotnet-ef things still don't work how I would expect.

➜  Company.DbContexts git:(develop) ✗ file ~/.dotnet/tools/dotnet-ef
/Users/username/.dotnet/tools/dotnet-ef: Mach-O 64-bit executable x86_64
➜  Company.DbContexts git:(develop) ✗ export DOTNET_ROOT=/usr/local/share/dotnet/x64 # same behavior with or without
➜  Company.DbContexts git:(develop) ✗ dnx64 ef database update --context MgxContext
Build started...
Build succeeded.
It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '5.0.0' (arm64) was not found.
  - The following frameworks were found:
      6.0.0-preview.2.21154.6 at [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
      6.0.0-rc.1.21451.13 at [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
      6.0.0-rc.2.21470.23 at [/usr/local/share/dotnet/shared/Microsoft.NETCore.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.NETCore.App&framework_version=5.0.0&arch=arm64&rid=osx.11.0-arm64

I expected this one to work because ef is x64 and I used dnx64 to call it, but it still seems to want to look for framework in the arm64 directory.

Doing

➜  Company.DbContexts git:(develop) ✗ export DOTNET_ROLL_FORWARD=LatestMajor
➜  Company.DbContexts git:(develop) ✗ dnx64 ef database update --context MgxContext
Build started...
Build succeeded.
Confirm that you want to apply the migrations to 'localhost' by typing: localhost
Confirm: localhost
No migrations were applied. The database is already up to date.
Done.

Coming from the thought that it is trying to find the framework version to use in the arm64 directory, I think it makes sense why DOTNET_ROLL_FORWARD lets this work, but I would also think that this shouldn't work because of the apparent arch mismatch.

I attached a trace where I was able to get this working, and one where it did not work.

From the trace it looks like ef isn't aware of to how to figure out the "correct" (x64) dotnet install to use to build the project. That makes sense in my mind why it seems to always fallback to the arm64 install to try and find the 5.0 framework.

Both cases were executed with dnx64 and both had DOTNET_ROOT=/usr/local/share/dotnet/x64. The working case is when I set DOTNET_ROLL_FORWARD=LatestMajor.

> cat /etc/dotnet/install_location
/usr/local/share/dotnet/x64
arm64=/usr/local/share/dotnet

working.txt
notworking.txt

[marinasundstrom]

Thanks you for the details!

I had to revert back to .NET 6 SDK RC1 (x64 macOS) when I realized that my tools stopped working in the ARM64 builds. Tye and so on, which are dependant on older framework versions.

After deleting and re-installing the frameworks,
The key to solving my next problem was:

cat /etc/dotnet/install_location
/usr/local/share/dotnet/x64

Opened the file and changed it to:

/usr/local/share/dotnet

Then everything is working again.

I will not update to .NET 6 for such an unstable release as RC2. I under-estimated the breaking changes.

[chan4lk]

I had the issue with running tye after installing rc 2. I followed @RobertSundstrom steps and got it working. Thank you.

[Meowzz95]

In my case, even dotnet run fail to lunch net5 projects when I installed both net5 and net6rc2 SDK. the error is libhostfxr.dylib mach-o file, but is an incompatible architecture

[vitek-karas]

To my knowledge the .NET 5 macOS x64 installer has not yet been updated to know about the different location on arm64 hardware. It should be available in 6.0 GA timeframe. But currently it will install "over" the arm64 6.0 RC2 install causing a mix of arm64 and x64 binaries on disk.

To be able to fully validate this, you can run export set COREHOST_TRACE=1, export set COREHOST_TRACEFILE=host.txt and then dotnet run net5app. This should produce a host.txt in the current directory which will contain details about where and why the hostfxr was loaded from.

[vitek-karas]

The latest update on the current state of things and what is planned for 6.0 GA is here: dotnet/sdk#22380.

[Meowzz95]

Just had to use dotnet ef today and it couldn't work without @tylermichael 's workaround (export DOTNET_ROLL_FORWARD=LatestMajor). The error is exactly same, I tried both dotnet-ef arm and dotnet-ef x64.

What I have installed:

Note: dotnet64 is alias dotnet64="/usr/local/share/dotnet/x64/dotnet"

➜ ~ dotnet64 --list-sdks

3.1.415 [/usr/local/share/dotnet/x64/sdk]

6.0.100 [/usr/local/share/dotnet/x64/sdk]

➜ ~ dotnet --list-sdks

6.0.100 [/usr/local/share/dotnet/sdk]

[sshquack]

I'm running into this exact same issue (see #26663). I'm a new dotnet dev on Apple M1.

My current pain points:

• Running into libhostfxr.dylib could not be found when launching dotnet-ef which prints an unhelpful error message
• The current VS for mac installer 8.10.13.2 (from here) only install dotnet 5 x64 5.0.11 but developers need 5.0.12
• When I tried to install the VS for mac 2022 preview 3, it throws an error to uninstall dotnet 5 and older to proceed.
• Installing the dotnet 5 x64 5.0.12 (from here) on top of VS for mac 8.10.13.2 causes zsh: command not found: dotnet
• The uninstall experience is a goose chase with some pointing to dotnet-uninstall-pkgs.sh (which hasn't been updated since 2019) and then there is dotnet-core-uninstall

The new developer experience is very confusing! Some suggestions to help improve this:

• Update the https://visualstudio.microsoft.com/vs/mac/ page with a big warning to make it clear that the current version will not work with M1 until .NET Support for macOS 11 and Windows 11 for Arm64 and x64 sdk#22380 is resolved
• Document that VS for mac 2019 and VS for mac 2022 preview can't be installed side-by-side on Apple M1
• Document steps on what a new dotnet developer should do to run a .NET 5 project on Apple M1
• Document steps on what a new dotnet developer should do to run .NET 5 and .NET 6 projects side-by-side on Apple M1
• Make the uninstaller be a simple macOS pkg that lets the user remove everything (VS, dotnet sdk, dotnet runtime) so they can start form the scratch quick

Thanks for all the hard work 🙏 I understand that there is a LOT of moving parts here and I'm looking forward to a smoother new dev install experience soon.

[reza-ariyan]

Try this out :
https://stackoverflow.com/questions/70929949/on-mac-m1-machine-not-able-to-run-ef-core-migrations-add-update-in-asp-net-co/71683322#71683322

[bricelam]

Workaround

You should be able to get it to work if you use the following to install it.

dotnet tool install -g -a arm64 dotnet-ef

[rebebop]

Workaround

You should be able to get it to work if you use the following to install it.

dotnet tool install -g -a arm64 dotnet-ef

Running this gives the following error

System.AggregateException: One or more errors occurred. (Resolving the current runtime identifier failed.)
 ---> Microsoft.DotNet.Cli.Utils.GracefulException: Resolving the current runtime identifier failed.
   at Microsoft.DotNet.Cli.CommonOptions.GetCurrentRuntimeId()
   at Microsoft.DotNet.Cli.CommonOptions.ResolveRidShorthandOptionsToRuntimeIdentifier(String os, String arch)
   at Microsoft.DotNet.ShellShim.ShellShimTemplateFinder.ResolveAppHostSourceDirectoryAsync(String archOption, NuGetFramework targetFramework, Architecture arch)
   --- End of inner exception stack trace ---
   at Microsoft.DotNet.Tools.Tool.Install.ToolInstallGlobalOrToolPathCommand.Execute()
   at Microsoft.DotNet.Tools.Tool.Install.ToolInstallCommand.Execute()
   at Microsoft.DotNet.Cli.DotNetTopLevelCommandBase.RunCommand(String[] args)
   at Microsoft.DotNet.Tools.Tool.ToolCommand.Run(String[] args)
   at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, TimeSpan startupTime, ITelemetry telemetryClient)
   at Microsoft.DotNet.Cli.Program.Main(String[] args)

However, this is working

Try this out : https://stackoverflow.com/questions/70929949/on-mac-m1-machine-not-able-to-run-ef-core-migrations-add-update-in-asp-net-co/71683322#71683322

[richlander]

The workaround version only works if two things are true:

• The .NET 6 SDK is 6.0.200+.
• A compatible x64 runtime is installed.

That makes it a not completely compelling workaround. It also needs to be better explained.

[pfeifix]

The workaround version only works if two things are true:

• The .NET 6 SDK is 6.0.200+.
• A compatible x64 runtime is installed.

That makes it a not completely compelling workaround. It also needs to be better explained.

Can you point me to a workaround I can apply to make the following work on Windows ARM64? I have installed .NET SDK 6.0.202 using the ARM64 installer (which contains the .NET runtimes, see https://dotnet.microsoft.com/en-us/download/dotnet/6.0). Executing

dotnet ef migrations add InitialCreate

on my ASP.NET Core project yields

Failed to load the dll from [C:\Program Files\dotnet\host\fxr\6.0.4\hostfxr.dll], HRESULT: 0x800700C1
The library hostfxr.dll was found, but loading it from C:\Program Files\dotnet\host\fxr\6.0.4\hostfxr.dll failed
  - Installing .NET prerequisites might help resolve this problem.
     https://go.microsoft.com/fwlink/?linkid=798306

[richlander]

As a test, can you try (before running that command):

set DOTNET_ROLL_FORWARD=Major

[pfeifix]

As a test, can you try (before running that command):

set DOTNET_ROLL_FORWARD=Major

Tried. Same Error shown.

[richlander]

Can you enable tracing and share the result (preferably as a link to a gist)?

Instructions: https://github.com/dotnet/runtime/blob/main/docs/design/features/host-tracing.md

[pfeifix]

Update: I just found out that issuing

dotnet tool update --global dotnet-ef

updated the version to 6.0.4. After that the migration command works as expected. I am happy now. Thanks for your help anyway!

[richlander]

Strange. Glad to hear that it helped. I don't know why, however.

[agocke]

Can you point me to a workaround I can apply to make the following work on Windows ARM64?

I believe adding -a arm64 to the dotnet install command will allow it to run on ARM64. The long-term fix here is for ef core to add a NET 6 target, as tracked at #27807

I also don't know why the dotnet tool update worked. :) That may also be a bug.

[pfeifix]

Strange. Glad to hear that it helped. I don't know why, however.

Hmm... ;-)

I believe adding -a arm64 to the dotnet install command will allow it to run on ARM64. The long-term fix here is for ef core to add a NET 6 target, as tracked at #27807

I think the ef CLI tools were already installed as ARM64 binaries. At least they were identical to the ARM64 ones provided on https://dotnet.microsoft.com/en-us/download/dotnet/6.0 (I did a binary comparison).

[richlander]

Back to the actual issue ... upon further investigation, we actually need this package to do two things:

• Multi-target 3.1 and .NET 6
• Add a shim for Windows Arm64

For folks reading this, the shim isn't something that most tools creators need to worry about. It's a Microsoft policy for signing binaries and doesn't apply to others (although anyone is free to do it). We may do the same for Linux and macOS later, but we're starting with completing the full set of supported Windows architectures for the moment.

[richlander]

Thanks @bricelam!

[roofiq]

Update: I just found out that issuing

dotnet tool update --global dotnet-ef

updated the version to 6.0.4. After that the migration command works as expected. I am happy now. Thanks for your help anyway!

hey @preetikr, I'm using version 6.0.5 and still getting error. Could it be that 6.0.4 is the only working one?