runtime: .NET Global Tools fail to launch of Apple Silicon
This is my experience on Big Sur 11.3 (Apple Silicon).
rich@MacBook-Air ~ % rm -r .dotnet/tools
rich@MacBook-Air ~ % dotnet tool list -g
Package Id Version Commands
-------------------------------------
rich@MacBook-Air ~ % dotnet tool install -g dotnet-runtimeinfo
You can invoke the tool using the following command: dotnet-runtimeinfo
Tool 'dotnet-runtimeinfo' (version '1.0.4') was successfully installed.
rich@MacBook-Air ~ % dotnet-runtimeinfo
zsh: killed dotnet-runtimeinfo
rich@MacBook-Air ~ % codesign -s - ~/.dotnet/tools/dotnet-runtimeinfo
rich@MacBook-Air ~ % dotnet-runtimeinfo
**.NET information
Version: 6.0.0
FrameworkDescription: .NET 6.0.0-preview.3.21201.4
Libraries version: 6.0.0-preview.3.21201.4
Libraries hash: 236cb21e3c1992c8cee6935ce67e2125ac4687e8
**Environment information
OSDescription: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar 5 01:14:02 PST 2021; root:xnu-7195.101.1~3/RELEASE_ARM64_T8101
OSVersion: Unix 11.3.0
OSArchitecture: Arm64
ProcessorCount: 8
rich@MacBook-Air ~ % dotnet runtimeinfo
**.NET information
Version: 6.0.0
FrameworkDescription: .NET 6.0.0-preview.3.21201.4
Libraries version: 6.0.0-preview.3.21201.4
Libraries hash: 236cb21e3c1992c8cee6935ce67e2125ac4687e8
**Environment information
OSDescription: Darwin 20.4.0 Darwin Kernel Version 20.4.0: Fri Mar 5 01:14:02 PST 2021; root:xnu-7195.101.1~3/RELEASE_ARM64_T8101
OSVersion: Unix 11.3.0
OSArchitecture: Arm64
ProcessorCount: 8
codesign is the missing link. I think we need to run it upon installation of .NET global tools.
I do not see the behavior for x64 emulation. It is apparently subject to different rules.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 28 (26 by maintainers)
Yep, works on both. We made the relevant changes in Microsoft.NET.HostModel a few weeks ago (unfortunately these didn’t make it to preview 6).
The SDK global tool install code eventually calls into the SDK’s ShellShim code to create the apphost, but actual apphost creation is handled by the runtime’s HostModel code. (Specifically HostWriter.CreateAppHost). That code would be area-HostModel.
There are two approaches.
One option is to run Apple’s
codesigntool, which is only going to be available on Apple platforms. (It is open source, so in theory creating a cut down version that can run on other platforms might be possible, but the C# approach would probably be simpler). This has the limitation that other scenarios like cross-platform publish won’t work on Apple Silicon. For this scenario, it is not completely clear to me if the code to do that definitely belongs in the HostModel code or if it might belong elsewhere, but the team in charge of the HostModel can help determine that.The other option is to have C# code directly generate the ad-hoc signature. If we did that, it unquestionably belongs in the HostModel code (the existing code to remove signatures lives there). Other languages (including golang) are taking this approach. So porting what they do might be possible.
Hope this helps.
I just wiped my Apple Silicon Big Sur machine. First thing after initial boot, open terminal window:
Thanks @sdmaclea. We have heard in the past that codesign is an OS component and does not require xcode. I agree it would be good to verify that will continue as we take a dependency on it.
Ugh, is this a by product that global tools are shipped as agnostic and then ‘created’ on the box with an apphost? That is unfortunate. Local codesign may work, but we would need to understand how codesign interacts with the developers identity and ensure this global resource is setup etc.