Support for .NET debugging on Apple M1 (and ARM64)

[philliphoff]

Updated debuggers for .NET are coming soon that support arm64 (in particular, the Apple M1). We need some changes to our debugging infrastructure to ensure the proper debugger is used within a arm64 container. See the PoC. The logic could be a bit more nuanced to eliminate downloading debuggers unnecessarily, and the "attach" scenario needs updating as well.

Test matrix for launch and attach scenarios:

Tested	OS	OS Arch	Container Arch	Notes
✅	Mac	amd64 (Intel)	amd64	Tested successfully.
✅	Mac	amd64 (Intel)	amd64 (alpine)	Tested successfully.
✅	Mac	arm64 (M1)	arm64	Tested successfully.
✅	Mac	arm64 (M1)	arm64 (alpine)	Tested successfully.
❓	Mac	arm64 (M1)	amd64 (emulated)	12 Jan 2022: Application runs in the debugger, but no breakpoints set are hit. Note: Error on building image: qemu: uncaught target signal 11 (Segmentation fault) - core dumped
❓	Mac	arm64 (M1)	amd64 (emulated) (alpine)	12 Jan 2022: Application runs in the debugger, but no breakpoints set are hit. Note: Error on building image: qemu: uncaught target signal 11 (Segmentation fault) - core dumped
✅	Linux	amd64 (Intel)	amd64	Tested successfully.
✅	Linux	amd64 (Intel)	amd64 (alpine)	Tested successfully.
❌	Linux	aarch64	aarch64	12 Jan 2022: Not yet supported by OmniSharp.
❌	Linux	aarch64	aarch64 (alpine)	12 Jan 2022: Not yet supported by OmniSharp.
✅	Windows	amd64 (Intel)	amd64	Tested successfully.
✅	Windows	amd64 (Intel)	amd64 (alpine)	Tested successfully.
❓	Windows	arm64	arm64	12 January 2022: Need special hardware in order test this scenario, as Parallels does not support nested virtualization with the M1 Mac

[bwateratmsft]

Is the 'blocked' tag for awaiting the release of vsdbg?

[philliphoff]

Yes.

[Jonatthu]

@philliphoff where is this vsdbg being tracked?

[philliphoff]

As of 25 May, the debugger acquisition scripts have been updated to return arm64 flavors, so we should now be unblocked.

[Vikas413]

when is this expected to release? currently it is blocking any docker dependent dev stuff on MAC M1 :(.

tried to use linux/amd64 based images but that is failing to start the app due to .net core is based on ARM not AMD. not sure my analysis is correct or not!

[karolz-ms]

@Vikas413 probably in the next extension release. They happen every month, typically

[philliphoff]

So, it looks like OmniSharp doesn't yet support arm64 in general (e.g. aarch64 Linux) so, in the interim, we probably just want to ensure that the extension picks up the ARM64 debuggers only on MacOS, and we might further restrict it to only on M1 Macs (even though it looks like Docker may support emulation in either direction).

Also, since we pull down the debuggers during debug configuration resolution, which is before the image is actually created, we don't have an easy way to determine the architecture of the resulting image. (There will be many factors that funnel into that, from the architecture of the host, to the architectures supported by the base image, to platform parameters passed to the build command (directly or via environment variables), etc.) I'm not sure if there's a much better way than just pulling them all down, ideally in parallel in order to minimize the extra hit.

[philliphoff]

@Vikas413 @Jonatthu @jp4u There is now some limited support for arm64 in the nightly builds (which should be enough to unblock Apple M1 users), if you'd like to try it out. If so, you can download the artifacts here, extract vscode-docker.1.13.1-alpha.vsix and install it manually in VS Code.

Let me know if you run into problems.

[Vikas413]

@philliphoff now it is different issue, check below log.

Failed to create CoreCLR, HRESULT: 0x8007FF06
The program '[32] dotnet' has exited with code 137 (0x89).
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.

I am using default docker file which is been generated by project template as given below.

FROM --platform=linux/amd64 mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM --platform=linux/amd64 mcr.microsoft.com/dotnet/sdk:5.0-buster AS build
WORKDIR /src
COPY HelloWorld/HelloWorld.csßßßproj HelloWorld/
RUN dotnet restore "HelloWorld/HelloWorld.csproj"
COPY . .
WORKDIR "/src/HelloWorld"
RUN dotnet build "HelloWorld.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "HelloWorld.csproj" -c Release -o /app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "HelloWorld.dll"]

any thought? how to resolve this.

[philliphoff]

@Vikas413 It looks like you're trying to debug in an amd64 container from your arm64 M1 Mac. I haven't been able to get this combination working on my own M1 yet. (I get QEMU errors.) Instead, what we've (hopefully) unblocked is debugging of arm64 containers.

[Vikas413]

@philliphoff yes, you are correct I am trying to debug, as that' what is most important thing for developers like me. what are our options here? even running it in release mode is also failing with below error.

HelloWorld/HelloWorld.csproj HelloWorld/
#11 sha256:90b2172db129fd7c775a5df7eeb63fd75241da989270f36f6d3c2a905599c2c4
#11 DONE 0.0s
#12 [build 4/7] RUN dotnet restore "HelloWorld/HelloWorld.csproj"
#12 sha256:3581c0768951a52218f20061da56b07cfd33dd64d77af2e7988360151c6b0837
#12 0.246 Failed to create CoreCLR, HRESULT: 0x8007FF06
#12 ERROR: executor failed running [/bin/sh -c dotnet restore "HelloWorld/HelloWorld.csproj"]: exit code: 137

breaking at 'RUN dotnet restore "HelloWorld/HelloWorld.csproj"' step

[philliphoff]

@Vikas413 I see the same thing when running an amd64 .NET 5 (buster-slim) application in a container on my M1. Unfortunately, that's a sign that there's something more fundamental in the amd64 emulation layer preventing use of .NET 5, and not something specific to the act of debugging that can be managed by the Docker extension.

The only suggestion I have, which works for me, is to remove the --platform=linux/amd64 from the FROM statements in your Dockerfile, so that Docker will use the native arm64 flavor of the images. That should at least allow you to debug/test in a container on your M1. Then, if you ultimately need amd64 versions of the container to use elsewhere, re-build the image using the --platform CLI argument.

[ktitrust]

@philliphoff Has there been any recent updates to this topic? I tested your suggestion in the last comment by removing the platform flag and even tested specifying platform tag as --platform=arm64 inside the dockerfile but I'm still receiving errors. I attempted attaching to pre-existing container spun up via docker compose as well as letting the debugger build the container from vs code. Container won't even build without crashing from debugger but when attaching to pre-existing it seems to come closer to working but when I set a break point it crashes the debugger with an attach error.

Here's my Dockerfile:

FROM --platform=arm64 mcr.microsoft.com/dotnet/sdk:5.0-buster-slim AS build

WORKDIR /app

COPY ./account /app

RUN dotnet publish ./src/Account.EntryPoint.csproj -c release -o out

FROM --platform=arm64 mcr.microsoft.com/dotnet/sdk:5.0-buster-slim

WORKDIR /app

COPY --from=build /app/out .

ENTRYPOINT ["dotnet", "Account.EntryPoint.dll"]

If I try to attach from within the container with attached vscode I get this:

[bwateratmsft]

Marking as blocked for now; there's things we need from external (.NET 6 GA, Omnisharp support, etc.).

[bwateratmsft]

.NET 6 is now GA'd. Omnisharp support has not yet arrived but seems to be close. I will move this to 1.20 since it will take time for that to become available.

[bwateratmsft]

@philliphoff is there anything more that needs to be done for this?

[bwateratmsft]

Discussed offline, @philliphoff will try out arm64 alpine container debugging (where breakpoints were not being hit but everything else appeared to work), to see if that issue still occurs. Other than that we will close this and await user feedback.

[philliphoff]

It looks like arm64 Alpine now works as expected (and I've updated the matrix). Debugging amd64 on M1 machines still does not work; that will take more investigation (if there's significant demand for it).

[bwateratmsft]

Awesome! We'll close this for now then, and await further feedback.