Enable ASP.NET Core on Apple Silicon

[sdmaclea]

Apple has announced plans to transition its Mac hardware line to a new Arm64-based chip that they refer to as “Apple Silicon

See dotnet/runtime#43313

This issue tracks work to enable ASP.NET Core on Apple Silicon

• Enable compilation on Apple Silicon
• Enable cross compilation from osx-x64
• Add arm64 support to SQLitePCL.raw osx universal binary Support Apple Silicon for e_sqlite3 ericsink/SQLitePCL.raw#375
• Add arm64 support to libuv osx universal binary (optional?) Libuv removed.
• Enable CI builds
• Enable testing

The first three items have been completed for the dotnet/runtime and should be able to proceed for aspnetcore.

Hints from dotnet/runtime learnings:

• Cross compilation requires Xcode 12.2 or better (included in vmImage 10.15)
• pass -arch arm64 to the clang compiler to select arm64 as the target architecture.

[sdmaclea]

Depends on a newer .NET 6 runtime. The current version is 4 days old. See #26693. Runtime 6.0.0-alpha.1.20509.10 seems to have a osx-arm64.

[sdmaclea]

Waiting on #26788

[JunTaoLuo]

@sdmaclea What's there left to do for this issue and is there anything we can help with?

For example I see the SQLitePCL.raw PR is merged and we have already deprecated libuv so we don't have to take any action there. Also it seems like in your PR #27264 the CI builds have been added, so is testing the only thing we need to track?

[sdmaclea]

I am not sure how the SQLitePCL.raw macos-arm64 bits will be released and picked up by ASP.NET Core. I assume ericsink/SQLitePCL.raw#375 is still open because the build hasn't been released?

I have not done even the slightest ASP.NET Core testing on Apple Silicon. When we have devices available, that would be useful.

Testing in CI needs to be enabled. The hardware to enable CI is on order. We expect to have CI queues enabled in January. I'll probably focus on enabling CI testing in dotnet/runtime first.

I am not sure how much platform specific testing is typically done in higher level repos. I would expect at least smoke testing. So dotnet/sdk, dotnet/installer, dotnet/aspnetcore testing could possibly be done in parallel. Otherwise I'll probably enable it when runtime testing is passing.

[sdmaclea]

From ericsink/SQLitePCL.raw#375 (comment)

Version 2.0.5-pre20201231105030 (which should address this issue) has been pushed up to nuget.org. Testing/verification appreciated. :-)

I have hardware availability, but I do not know what would be required to (even smoke) test it for .NET 6 on Apple Silicon.

[sdmaclea]

We have limited M1 testing capacity available. Due to the limited capacity, I do not plan to enable testing of ASP.NET on M1 (any time soon).

Also we need to wait on the M1 queue being updated to macOS 11.3 (once it is released). There are major stability fixes which greatly improve the runtime stability.

https://github.com/dotnet/core-eng/issues/11937#issuecomment-816110773

We still have a lot of runtime libraries testing to enable. There are a lot of failing tests. The 11.3 upgrade may fix most of them.

I am tempted to close this. Since ASP.NET is mostly managed code CI testing would only provide more runtime coverage. With limited M1 queue capacity, failures here would not likely be very actionable.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[JunTaoLuo]

I'll move this issue to Backlog. @sdmaclea Will the testing capacity increase at some point? If so should we enable our tests on apple silicon then? I'm also curious if our helix daily tests, which run twice a day on a set schedule, would be within the limits of the testing capacity available.

[sdmaclea]

The helix queues currently have capacity for scheduled test runs. Per PR runs would overwhelm them though. We have very short wait times at the moment.

[dougbu]

What are the queue names and can you handle our load for (say) daily runs❔

I'm also forgetting which branches (versions) this is important for. Please remind us.

[dougbu]

Separately, what action should(s) we take in dotnet/aspnetcore on unchecked items aside from testing❔

[xsoheilalizadeh]

Does #38527 cover Apple Silicon?
@dougbu

[dougbu]

Does #38527 cover Apple Silicon?

No, that PR was about building and testing locally on Linux Arm64 hardware.

[tebeco]

@sdmaclea @dougbu
hello ;)

I'm not sure how to interpret the status of this EPIC.
Is there still some scenario with AspNetCore causing issue on Apple Silicon?

• As a dev using aspnetcore
• as a dev doing PR on this repo
• something else ?

[dougbu]

@tebeco it's hard to see above but my understanding is our main remaining issue is a lack of regular testing on Apple Silicon. Fortunately we have enough information to be confident ASP.NET Core works on that hardware.

[tebeco]

thx for the quick reply @dougbu

do you think

• the checkox about sqlite should be checked now given sun or linked to that ?
• that "Enable testing" could be rephrased to clarify its only relevant to the infra of the ci but does not affect devs / contributor / etc ... ?

[dougbu]

@wtgodbe let's talk about this next Tuesday and decide what work remains. Also @HaoK did we ever run Helix tests on M1 queues❔

[dougbu]

@HaoK, more specifically, have you done a test run that included OSX.1100.Arm64.Open in the matrix❔

@dotnet/dnceng, could you confirm that queue is using M1 hardware❔

[jonfortescue]

@dougbu yep, they're M1s

[HaoK]

Our tests seem fine no failures on https://dev.azure.com/dnceng-public/public/_build/results?buildId=25795&view=ms.vss-test-web.build-test-results-tab

[dougbu]

Alright, @dotnet/aspnet-admin, we've tested on M1 hardware and the other points in the description are closed. Either we close this issue now or we explicitly make it about tracking the agent count in the OSX.1100.Arm64.Open queue and including that in our aspnetcore-helix-matrix runs when / if the queue is large enough. Thoughts❔

I lean slightly toward closing this issue because our Apple-related issues feel more tightly bound to OS changes than the hardware.

[HaoK]

I think we should just close this. I don't think we would get any particular benefit out of running on this special queue all the time given that we don't have any product code for this hardware

[tebeco]

that's one of the reason i'm asking.
It could really be misleading for anyone looking for Apple Silicon in this repo