Apple has announced plans to transition its Mac hardware line to a new Arm64-based chip that they refer to as “Apple Silicon”. This epic tracks the high level status of the milestones required to ship this feature in .NET 6.
.NET 6 will include new runtime id -- osx-arm64 -- for targeting this hardware. It refers to the macOS operating system running on Apple Silicon devices.
.NET 5 - CoreCLR
- [ ] Support .NET Core 5 with Rosetta 2 emulation #44897
.NET 6 - CoreCLR
Functionality
- [x] Support compilation targeting osx-arm64
- [x] Modify code generation to support osx-arm64 security features
- [ ] Modify code generation to support osx-arm64 interop with native libraries
Testing
- [x] Apple Silicon Prototype hardware available
- [x] Manual testing of basic inner and outer loop tests
- [x] Apple commercially shipping arm64 macos devices
- [ ] CI/CD Testing enabled
- [ ] CI/CD Stress testing enabled
Stability
- [x] Basic tests passing rate > 99%
- [ ] Stress tests passing rate > 99%
- [ ] All tests passing rate > 99.9%
Availability
- [x] .NET Core runtime nightly builds available
- [x] ASP.NET Core runtime nightly builds available dotnet/aspnetcore#26821 (unstable)
- [x] .NET Core SDK nightly builds available dotnet/installer#8840 (unstable)
- [ ] .NET 6 preview available
- [ ] .NET 6 release available
Details
See Enable .NET Core on Apple Silicon for the full set of related PRs and issues.
.NET 6 - Mono
Functionality
- [x] Support compilation targeting osx-arm64
- [x] Modify code generation to support osx-arm64 security features
- [x] Modify code generation to support osx-arm64 interop with native libraries
Testing
- [x] Apple Silicon Prototype hardware available
- [ ] Manual testing of basic inner and outer loop tests
- [ ] Apple commercially shipping arm64 macos devices
- [ ] CI/CD Testing enabled
- [ ] CI/CD Stress testing enabled
Stability
- [ ] Basic tests passing rate > 99%
- [ ] Stress tests passing rate > 99%
- [ ] All tests passing rate > 99.9%
Availability
- [ ] Runtime nightly builds available
- [ ] .NET 6 preview available
- [ ] .NET 6 release available
/cc @richlander @mangod9 @janvorli @JulieLeeMSFT @sandreenko @tommcdon @steveisok @directhex @akoeplinger @jeffschwMSFT
sdmaclea
All 39 comments
By the time .NET 6 is released, it will have been more than five years since Apple renamed this operating system to "macOS". It's not called "OS X" any more. If it can be done correctly in TFMs, it can be done correctly in RIDs.
warrenrumak
on 12 Oct 2020
Yup. Please file an issue @warrenrumak.
richlander
on 12 Oct 2020
For Mono, I think the work item "Modify code generation to support osx-arm64 interop with native libraries" is done in the sense that the ABI is the same as ios which we already support. Is that right, @vargaz ?
lambdageek
on 26 Oct 2020
For Mono, I think the work item "Modify code generation to support osx-arm64 interop with native libraries" is done in the sense that the ABI is the same as ios which we already support. Is that right, @vargaz ?
Indeed. Apple has confirmed to me that the Apple silicon Mac ABI is precisely the same as their iOS ARM ABI.
eschwieb
on 26 Oct 2020
Yes, we don't support the arm64e stuff, but otherwise mono works on osx/arm64, both in the old mono repo and in dotnet/runtime. Couldn't run test suites because the sdk tools were hanging.
vargaz
on 26 Oct 2020
@jeffschwMSFT I'm not sure if this is supposed to be a team epic. This was created with @richlander. I thought it was supposed to be a customer facing epic.
sdmaclea
on 26 Oct 2020
This feels like the right level of scope to me. Thank you for helping to keep our progress tracked and visible.
jeffschwMSFT
on 26 Oct 2020
Given how quick things are coming for true arm64 for apple in 6.0 perhaps it makes sense to make the changes for 5.0 rather than trying to make it work on rosetta 2?
ilushka85
on 20 Nov 2020
The belief is that people will want a supported .NET product on Apple Silicon before November 2021. That's why we are enabling 5.0 in R2 as well as enabling 6.0 to run natively. Also, there will be scenarios where 6.0 will need to run in R2 as well, so we might as well get that scenario working with 5.0.
richlander
on 20 Nov 2020
@richlander would be good to have it at least running via Rosetta 2 asap.
JaggerJo
on 20 Nov 2020
@JaggerJo that work is tracked via #44897.
mangod9
on 20 Nov 2020
@richlander while I agree it should likely support both... is there a chance of bringing the native support to 5.0 so that a wait for nov 2021 is not needed?
ilushka85
on 20 Nov 2020
We're going to finish adding functional-level Apple Silicon support to 6.0. At that point, we'll see the full set of changes that were required. We already think that the set of changes are too large to backport to 5.0, but we'll reserve judgment until later, and we'll also have a better sense of the market reaction/adoption to/of these devices (particularly around developers). In short, 5.0 native support is unlikely.
richlander
on 20 Nov 2020
How do you plan to measure adoption of those devices? Telemetry will be out of the question, I assume.
Just to add a data point: I am a long-time .NET developer who switched to macOS many years ago. I've ordered two of those M1 machines to check if they might speed up my Xamarin and F# compilations, assuming that it will at least work with Rosetta. Would be nice if I had not to wait for months to be able to actually do that.
aspnetde
on 20 Nov 2020
My network is not big but perhaps with the right sharing we will have an idea on the adoption...
https://twitter.com/galvesribeiro/status/1329895215549779973?s=21
galvesribeiro
on 20 Nov 2020
Would be nice if I had not to wait for months to be able to actually do that.
Understood. .NET 5 Rosetta 2 emulation will be the quickest to release.
We already think that the set of changes are too large to backport to 5.0, but we'll reserve judgment until later
The initial native Apple Silicon change #40435 was huge. This is something that would be difficult to accept into the main .NET 5.0 servicing branch. It would involve too much risk to other platforms.
I've ordered two of those M1 machines
Yes we have some on order too. These will help light up CI and are a prerequisite to shipping native or even officially supporting Rosetta 2 emulation.
sdmaclea
on 20 Nov 2020
I haven't seen anyone bring up this so let me ask about this. Does support Rosetta 2 emulation mean we will have a fully working .NET 5 SDK(under R2) which can build and debug our code or this is just runtime support?
Meowzz95
on 21 Nov 2020
@Meowzz95 from what I've tried the SDK seems to work fine. Things fall apart when you try to run an app.
JaggerJo
on 21 Nov 2020
@JaggerJo Are you able to debug the code? I can't even start the debugger(using Rider under Rosetta 2)...
Meowzz95
on 21 Nov 2020
Does support Rosetta 2 emulation mean we will have a fully working .NET 5 SDK(under R2) which can build and debug our code
We want a full .NET 5 SDK running under Rosetta 2 with MS debugger support. (I can't speak for Rider)
The current .NET 5 version sometimes works. We used it initially to build dotnet/runtime for Apple Silicon. It would hang most of the time during the build, but occasionally it would succeed. We think we understand the root cause of the hangs.
I haven't tried running a debugger yet with .NET 5 + R2. Kind of strange given I work on the debugger.
sdmaclea
on 21 Nov 2020
Most of our debugging works fine on R2 and .net core. The one place debugging does not work is Azure Functions. Debugger hangs on startup, but running without debugger is fine. See here: https://github.com/Azure/azure-functions-core-tools/issues/2303
ilushka85
on 21 Nov 2020
Well...
aspnetde
on 23 Nov 2020
When will the first stable release come? I just got the Macbook Air with the M1 chip and it's impossible for me to run Blazor applications :(
Good job though.
omic96
on 26 Nov 2020
We are continuing to make incremental progress, once we get CI enabled with new hardware we should have a better handle on work required to get to parity with x64. Thx!
mangod9
on 26 Nov 2020
Sounds good, best of luck with it, I'll be waiting :)
omic96
on 26 Nov 2020
So will I.
I decided to step by step move to the M1 MacBook Pro as it is such a great computer. It really is a step change from my point of view. Hopefully also with .NET 6 compilation times, and F# in particular 😄. Until we arrive there I will be happy to get good enough performance with Rosetta and .NET 5.
aspnetde
on 27 Nov 2020
Is there a reason why .NET will only support Apple Silicon in a year when all other programming languages will be there in Q1 of 2021? What blocks Microsoft engineers from dropping support in a couple months like quite literally everyone else?
dustinmoris
on 29 Nov 2020
@dustinmoris our current approach is to first get support for Apple Silicon functional and performant. Once we have that we can consider where to enable support. At this point our current target is .NET 6, which will start having public previews early next year.
jeffschwMSFT
on 30 Nov 2020
Does support Rosetta 2 emulation mean we will have a fully working .NET 5 SDK(under R2) which can build and debug our code
We want a full .NET 5 SDK running under Rosetta 2 with MS debugger support. (I can't speak for Rider)
The current .NET 5 version sometimes works. We used it initially to build dotnet/runtime for Apple Silicon. It would hang most of the time during the build, but occasionally it would succeed. We think we understand the root cause of the hangs.
I haven't tried running a debugger yet with .NET 5 + R2. Kind of strange given I work on the debugger.
I know you mentioned you wanted to get the 5.0 SDK running under Rosetta 2, would 3.1 also get the debugger issue fixed as well? Or would I need to upgrade my projects to 5.0 in order to use the debugger when that is addressed?
Nonary
on 30 Nov 2020
... Also, there will be scenarios where 6.0 will need to run in R2 as well, so we might as well get that scenario working with 5.0.
@richlander Could you please elaborate why 6.0 would need R2 sometimes?
xhafan
on 30 Nov 2020
Could you please elaborate why 6.0 would need R2 sometimes?
@xhafan I'm not @richlander, but one such situation would be if your app has native x86 components that can't/won't be ported to ARM.
PathogenDavid
on 30 Nov 2020
The other reason is that someone builds an app only for macOS x64 and people want it to run in on M1. Clearly, that's not preferred, but it is a scenario that should work.
richlander
on 1 Dec 2020
The other reason is that someone builds an app only for macOS x64 and people want it to run in on M1. Clearly, that's not preferred, but it is a scenario that should work.
Really? Not sure if this is really a use case which needs support. Sounds like a hack. If an app is purposefully only build against macOS x64 then perhaps it should remain that way. If people want to run that app on M1 then they can pull the source and compile it themselves. If that is not possible then they should reach out to the developer of that app. Why overcomplicate things?
dustinmoris
on 1 Dec 2020
Really? Not sure if this is really a use case which needs support. Sounds like a hack. If an app is purposefully only build against macOS x64 then perhaps it should remain that way. If people want to run that app on M1 then they can pull the source and compile it themselves. If that is not possible then they should reach out to the developer of that app. Why overcomplicate things?
Its no more a hack than Rosetta2 is a hack. Wouldn't need emulation at all if recompiling everything was as simple as you say. Fact is, x86 code is expected to work on MacOS for the foreseeable future, and I don't hear a compelling reason to treat .NET apps differently.
jherby2k
on 1 Dec 2020
I would say that, if .Net can run under Rosetta2 at least at the same acceptable performance at development time as it is on Intel Macs (some apps have been running 20-30% faster!), then it would be just fine to keep waiting for .Net 6 and use Rosetta2 for now.
I think the majority of people now that will use .Net on those M1s are developers and not final users so if they can at least use Rosetta2 to properly run VSCode/VSforMac and .Net extensions, they would survive.
Not running at all like in @aspnetde picture is what concern most of people...
Perhaps the adoption of .Net 6 previews will be way bigger than .Net 5 on Mac world if Rosetta2 will not become a viable option. 😄
galvesribeiro
on 1 Dec 2020
Not running at all like in @aspnetde picture is what concern most of people...
To be fair, compiling worked and was as fast as on my then maxed-out 2016 MBP 15“. Only „the debugger“ crashed.
aspnetde
on 1 Dec 2020
The belief is that people will want a supported .NET product on Apple Silicon before November 2021.
That really is a disappointment for me :(. Meanwhile the java people are churning out ready-to-use OpenJDK M1 builds which just work (for versions down to 8).
Keep up the good work and perhaps there will be a M1 build in less than 1 year :). I just hope so.
Regards,
Andreas
schipplock
on 2 Dec 2020
.Net dying on my M1 left and right.
I did have my Angular/Core project up and running with a custom configuration (didnt actually change any config), but after a VS update, the Core project will not run at all...at least I can play with angular and VS Code...but a little underwhelming without my API running
jeffreylongo
on 2 Dec 2020
.Net dying on my M1 left and right.
I did have my Angular/Core project up and running with a custom configuration (didnt actually change any config), but after a VS update, the Core project will not run at all...at least I can play with angular and VS Code...but a little underwhelming without my API running
Very sorry to hear! We are tracking known Rosetta 2 issues on #44897.
tommcdon
on 2 Dec 2020
Related issues
ghost
·
230Comments
ebickle
·
318Comments
fiigii
·
181Comments
terrajobst
·
158Comments
syeshchenko
·
199Comments
Most helpful comment
By the time .NET 6 is released, it will have been more than five years since Apple renamed this operating system to "macOS". It's not called "OS X" any more. If it can be done correctly in TFMs, it can be done correctly in RIDs.