dotnet-ef needs to target 6

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?

@richlander

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.

@marcpopMSFT

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.

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?

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.

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?

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

@marcpopMSFT

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

dotnet/sdk#18889
and
dotnet/sdk#18832

@wli3

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

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.

@richlander

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.

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.

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.

@sfoslund

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

@tylermichael

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.

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

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.

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).

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.

Tools: Target .NET 6 to improve compatibility with osx-arm64

@bricelam

Thanks @bricelam!

@preetikr

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?

Navigation Menu

Repository navigation

dotnet-ef needs to target 6 #27787

27 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

dotnet-ef needs to target 6 #27787

Description

Activity

ericstj commented on Sep 29, 2021

agocke commented on Sep 29, 2021

joeloff commented on Sep 29, 2021

vitek-karas commented on Sep 29, 2021

agocke commented on Sep 29, 2021

tylermichael commented on Sep 29, 2021

wli3 commented on Sep 29, 2021

wli3 commented on Sep 29, 2021

richlander commented on Sep 29, 2021

agocke commented on Sep 29, 2021

wli3 commented on Sep 29, 2021

marcpopMSFT commented on Sep 29, 2021

agocke commented on Sep 29, 2021

richlander commented on Sep 29, 2021

vitek-karas commented on Sep 30, 2021

27 remaining items

richlander commented on Apr 26, 2022

agocke commented on Apr 26, 2022

pfeifix commented on Apr 26, 2022

richlander commented on Apr 27, 2022

richlander commented on May 15, 2022

roofiq commented on May 18, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions