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.