You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following is my experience of installing a global tool on Apple Silicon. I installed a tool using the Arm64 SDK. It then tells me that it requires .NET 5, which we know doesn't have an Arm64 version. I had to re-install it with the x64 SDK for it to work.
rich@MacBook-Air ~ % dotnet tool install -g dotnet-serve
Tools directory '/Users/rich/.dotnet/tools' is not currently on the PATH environment variable.
If you are using zsh, you can add it to your profile by running the following command:
cat << \EOF >> ~/.zprofile# Add .NET Core SDK toolsexport PATH="$PATH:/Users/rich/.dotnet/tools"EOF
And run `zsh -l` to make it available for current session.
You can only add it to the current session by running the following command:
export PATH="$PATH:/Users/rich/.dotnet/tools"
You can invoke the tool using the following command: dotnet-serve
Tool 'dotnet-serve' (version '1.8.34') was successfully installed.
rich@MacBook-Air ~ % export PATH="$PATH:/Users/rich/.dotnet/tools"
rich@MacBook-Air ~ % dotnet-serve
zsh: killed dotnet-serve
rich@MacBook-Air ~ % codesign -s - .dotnet/tools/dotnet-serve
rich@MacBook-Air ~ % dotnet-serve
It was not possible to find any compatible framework version
The framework 'Microsoft.AspNetCore.App', version '5.0.0' was not found.
- The following frameworks were found:
6.0.0-preview.3.21201.13 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.0-arm64
rich@MacBook-Air ~ % dotnet tool uninstall -g dotnet-serve
Tool 'dotnet-serve' (version '1.8.34') was successfully uninstalled.
rich@MacBook-Air ~ % /usr/local/share/dotnet/x64/dotnet tool install -g dotnet-serve
You can invoke the tool using the following command: dotnet-serve
Tool 'dotnet-serve' (version '1.8.34') was successfully installed.
rich@MacBook-Air ~ % dotnet-serve
I installed the first tool that came to mind that I thought wouldn't have a .NET 6 version (and I expected didn't roll forward). I was right. As a user, I then need to know which SDK to use to install it so that a compatible app host will be created.
Here are two UX scenarios I think would be workable, in order of perference:
dotnet tool install is smart enough to realize that the implicit RID of the SDK is not compatible with the global tool and produces/generates a compatible one instead.
dotnet tool install produces an error that the tool isn't compatible with the architecture of the SDK RID and asks you to install the tool with an architecture, like dotnet tool install -a x64 -g dotnet-serve. This would give the user an opportunity to validate that they have the required runtime version installed.
richlander
changed the title
.NET Global tools create app launch for wrong architecture on Apple Silicon
.NET Global tools create applaunch executable for wrong architecture on Apple Silicon
Apr 28, 2021
The user can get in trouble if they have an X64 and an Arm64 installation. Let's ignore that for now.
Tools with chip specific code may not work on Arm64. That's as today, let's ignore for now.
If the user installs a <6.0 tool from an Arm64 SDK, it will not work if we do not alter dotnet tool install to recognize <6.0 and use an appropriate AppHost
The following is my experience of installing a global tool on Apple Silicon. I installed a tool using the Arm64 SDK. It then tells me that it requires .NET 5, which we know doesn't have an Arm64 version. I had to re-install it with the x64 SDK for it to work.
I installed the first tool that came to mind that I thought wouldn't have a .NET 6 version (and I expected didn't roll forward). I was right. As a user, I then need to know which SDK to use to install it so that a compatible app host will be created.
Here are two UX scenarios I think would be workable, in order of perference:
dotnet tool install
is smart enough to realize that the implicit RID of the SDK is not compatible with the global tool and produces/generates a compatible one instead.dotnet tool install
produces an error that the tool isn't compatible with the architecture of the SDK RID and asks you to install the tool with an architecture, likedotnet tool install -a x64 -g dotnet-serve
. This would give the user an opportunity to validate that they have the required runtime version installed.Some overlap with https://github.com/dotnet/sdk/issues/17143
The text was updated successfully, but these errors were encountered: