wasm-tools workload isn't supported on arm64 version of Docker

[romansp]

Describe the bug

wasm-tools workload cannot be installed using default SDK base image on arm64 version of Docker.

Default SDK image resolves to debian.11-arm64 runtime here. Current workaround is to force amd64 base image on M1 Mac, e.g. use mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim-amd64 as base which isn't ideal.

Switching to 7.0 SDK preview doesn't help either.

What made it really confusing is that installation of wasm-tools on M1 Mac host works just fine. And subsequent dotnet publish of Blazor wasm project with AOT compilation enabled completes successfully.

So I'm not quite sure if that's indeed a bug, expected behavior for default SDK image on arm64 or something that's going to be resolved soon?

To Reproduce

Use the following Dockerfile

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
RUN dotnet workload install wasm-tools

Exceptions (if any)

=> ERROR [2/2] RUN dotnet workload install wasm-tools                                                                                                                                                                   0.3s
------                                                                                                                                                                                                                        
> [2/2] RUN dotnet workload install wasm-tools:
dotnet/sdk#6 0.256 Workload ID wasm-tools isn't supported on this platform.
------
executor failed running [/bin/sh -c dotnet workload install wasm-tools]: exit code: 1

Further technical details

• Output of dotnet --info from inside Docker build context

dotnet/sdk#6 [3/4] RUN dotnet --info
dotnet/sdk#6 sha256:e12c7930a3013f8d3ae721ad9273a620d104a3354f242487ffc0710527bbb843
dotnet/sdk#6 0.217 .NET SDK (reflecting any global.json):
dotnet/sdk#6 0.217  Version:   6.0.400
dotnet/sdk#6 0.217  Commit:    7771abd614
dotnet/sdk#6 0.217 
dotnet/sdk#6 0.217 Runtime Environment:
dotnet/sdk#6 0.218  OS Name:     debian
dotnet/sdk#6 0.218  OS Version:  11
dotnet/sdk#6 0.219  OS Platform: Linux
dotnet/sdk#6 0.227  RID:         debian.11-arm64
dotnet/sdk#6 0.227  Base Path:   /usr/share/dotnet/sdk/6.0.400/
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 global.json file:
dotnet/sdk#6 0.227   Not found
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 Host:
dotnet/sdk#6 0.227   Version:      6.0.8
dotnet/sdk#6 0.227   Architecture: arm64
dotnet/sdk#6 0.227   Commit:       55fb7ef977
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 .NET SDKs installed:
dotnet/sdk#6 0.227   6.0.400 [/usr/share/dotnet/sdk]
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 .NET runtimes installed:
dotnet/sdk#6 0.227   Microsoft.AspNetCore.App 6.0.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
dotnet/sdk#6 0.227   Microsoft.NETCore.App 6.0.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 Download .NET:
dotnet/sdk#6 0.227   https://aka.ms/dotnet-download
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 Learn about .NET Runtimes and SDKs:
dotnet/sdk#6 0.227   https://aka.ms/dotnet/runtimes-sdk-info
dotnet/sdk#6 DONE 0.2s

• Apple M1 Mac, macOS Monterrey 12.5.1
• Docker Desktop for Apple Chip, 4.11.1 (84025)

[joeloff]

We don't have full arm64 support for workload yet. Especially around some of the external tools that some workloads carry. We are looking at potentially aliasing some packs against the x64 content and letting those run under emulation for native arm64 sdk installs.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[joeloff]

@lewing do you know the timeframe for adding arm64 support for wasm-tools?

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Describe the bug

wasm-tools workload cannot be installed using default SDK base image on arm64 version of Docker.

Default SDK image resolves to debian.11-arm64 runtime here. Current workaround is to force amd64 base image on M1 Mac, e.g. use mcr.microsoft.com/dotnet/sdk:6.0-bullseye-slim-amd64 as base which isn't ideal.

Switching to 7.0 SDK preview doesn't help either.

What made it really confusing is that installation of wasm-tools on M1 Mac host works just fine. And subsequent dotnet publish of Blazor wasm project with AOT compilation enabled completes successfully.

So I'm not quite sure if that's indeed a bug, expected behavior for default SDK image on arm64 or something that's going to be resolved soon?

To Reproduce

Use the following Dockerfile

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
RUN dotnet workload install wasm-tools

Exceptions (if any)

=> ERROR [2/2] RUN dotnet workload install wasm-tools                                                                                                                                                                   0.3s
------                                                                                                                                                                                                                        
> [2/2] RUN dotnet workload install wasm-tools:
dotnet/sdk#6 0.256 Workload ID wasm-tools isn't supported on this platform.
------
executor failed running [/bin/sh -c dotnet workload install wasm-tools]: exit code: 1

Further technical details

• Output of dotnet --info from inside Docker build context

dotnet/sdk#6 [3/4] RUN dotnet --info
dotnet/sdk#6 sha256:e12c7930a3013f8d3ae721ad9273a620d104a3354f242487ffc0710527bbb843
dotnet/sdk#6 0.217 .NET SDK (reflecting any global.json):
dotnet/sdk#6 0.217  Version:   6.0.400
dotnet/sdk#6 0.217  Commit:    7771abd614
dotnet/sdk#6 0.217 
dotnet/sdk#6 0.217 Runtime Environment:
dotnet/sdk#6 0.218  OS Name:     debian
dotnet/sdk#6 0.218  OS Version:  11
dotnet/sdk#6 0.219  OS Platform: Linux
dotnet/sdk#6 0.227  RID:         debian.11-arm64
dotnet/sdk#6 0.227  Base Path:   /usr/share/dotnet/sdk/6.0.400/
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 global.json file:
dotnet/sdk#6 0.227   Not found
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 Host:
dotnet/sdk#6 0.227   Version:      6.0.8
dotnet/sdk#6 0.227   Architecture: arm64
dotnet/sdk#6 0.227   Commit:       55fb7ef977
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 .NET SDKs installed:
dotnet/sdk#6 0.227   6.0.400 [/usr/share/dotnet/sdk]
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 .NET runtimes installed:
dotnet/sdk#6 0.227   Microsoft.AspNetCore.App 6.0.8 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
dotnet/sdk#6 0.227   Microsoft.NETCore.App 6.0.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 Download .NET:
dotnet/sdk#6 0.227   https://aka.ms/dotnet-download
dotnet/sdk#6 0.227 
dotnet/sdk#6 0.227 Learn about .NET Runtimes and SDKs:
dotnet/sdk#6 0.227   https://aka.ms/dotnet/runtimes-sdk-info
dotnet/sdk#6 DONE 0.2s

• Apple M1 Mac, macOS Monterrey 12.5.1
• Docker Desktop for Apple Chip, 4.11.1 (84025)

Author:	romansp
Assignees:	joeloff
Labels:	arch-wasm, untriaged
Milestone:	-

[mphilipp622]

I see this was added to the .net 8 milestone. Just curious if there are any workarounds for getting this workload installed on arm64 linux until .net 8 is out of preview. Any recommendations? My server is an arm64 AWS Linux 2022 instance, which is, essentially, a custom Fedora distro.

Currently, if I want to publish blazor with AOT, I need to do it on my Windows machine and copy the contents up to my Linux server to host the AOT build. Not the worst workflow, but not my preference, either. Thanks!

[marek-safar]

@directhex do you have any tips?

[directhex]

That's expected at this point, we don't have a Linux ARM64 workload https://github.com/dotnet/runtime/blob/main/src/mono/nuget/Microsoft.NET.Workload.Mono.Toolchain.Current.Manifest/WorkloadManifest.json.in#L15

Right now, our EMSDK "builds" are just packaging up x64 upstream binaries in nupkgs - and Docker wouldn't typically allow running x64 binaries on arm64 images on arm64 out of the box (the way Windows and macOS do). Yes, that includes our win-arm64 and osx-arm64 workloads - the stuff we build is native ARM64 now, but we're just shipping x64 EMSDK.

There is a project to do in-house builds of EMSDK, from our ARM64 team, and they've pretty much finished their research and proposed build system changes - I just haven't had the time to consume those yet (I'm working on the same build-it-in-house approach for WASI, which will explicitly support ARM64 from day one).

Definitely planned, and in progress, but not ready yet, even in nightlies. Watch this space.

[directhex]

This issue isn't forgotten. The PR for adding native arm64 packages (Linux, Mac, Windows) should go up within a week, hopefully merged by the end of next week. I just got my first native linux-arm64 package built