-->
Currently, Visual Studio for Mac only supports the following technologies With Visual Studio for Mac you can write in C#, F#, Razor, HTML5, CSS, Javascript, Typescript, XAML, and XML Compare Visual Studio for Mac and PC. Visual Studio Code C# (MacBook Pro Apple M1) Debug not working. There are new insider build which supports M1 Mac with ARM64 options from here visual studio.
If you have an M1 and find any issues with Visual Studio for Mac please report a problem on the Developer Community. Hopefully you found this pretty interesting if you are in the market for an M1 or have just been struggling to figure out this new landscape of ARM64 recompiled apps.
In this article, you'll learn how to install .NET on macOS. .NET is made up of the runtime and the SDK. The runtime is used to run a .NET app and may or may not be included with the app. The SDK is used to create .NET apps and libraries. The .NET runtime is always installed with the SDK.
The latest version of .NET is 5.0.
Supported releases
The following table is a list of currently supported .NET releases and the versions of macOS they're supported on. These versions remain supported either the version of .NET reaches end-of-support.
- A ✔️ indicates that the version of .NET Core is still supported.
- A ❌ indicates that the version of .NET Core isn't supported.
| Operating System | .NET Core 2.1 | .NET Core 3.1 | .NET 5.0 |
|---|---|---|---|
| macOS 11.0 'Big Sur' | ✔️ 2.1 (Release notes) | ✔️ 3.1 (Release notes) | ✔️ 5.0 (Release notes) |
| macOS 10.15 'Catalina' | ✔️ 2.1 (Release notes) | ✔️ 3.1 (Release notes) | ✔️ 5.0 (Release notes) |
| macOS 10.14 'Mojave' | ✔️ 2.1 (Release notes) | ✔️ 3.1 (Release notes) | ✔️ 5.0 (Release notes) |
| macOS 10.13 'High Sierra' | ✔️ 2.1 (Release notes) | ✔️ 3.1 (Release notes) | ✔️ 5.0 (Release notes) |
| macOS 10.12 'Sierra' | ✔️ 2.1 (Release notes) | ❌ 3.1 (Release notes) | ❌ 5.0 (Release notes) |
Unsupported releases
The following versions of .NET are ❌ no longer supported. The downloads for these still remain published:
- 3.0 (Release notes)
- 2.2 (Release notes)
- 2.0 (Release notes)
Runtime information
The runtime is used to run apps created with .NET. When an app author publishes an app, they can include the runtime with their app. If they don't include the runtime, it's up to the user to install the runtime.
There are two different runtimes you can install on macOS:
ASP.NET Core runtime
Runs ASP.NET Core apps. Includes the .NET runtime..NET runtime
This runtime is the simplest runtime and doesn't include any other runtime. It's highly recommended that you install ASP.NET Core runtime for the best compatibility with .NET apps.
SDK information
The SDK is used to build and publish .NET apps and libraries. Installing the SDK includes both runtimes: ASP.NET Core and .NET.
Dependencies
.NET is supported on the following macOS releases:
| .NET Core Version | macOS | Architectures | More information |
|---|---|---|---|
| 5.0 | High Sierra (10.13+) | x64 | More information |
| 3.1 | High Sierra (10.13+) | x64 | More information |
| 3.0 | High Sierra (10.13+) | x64 | More information |
| 2.2 | Sierra (10.12+) | x64 | More information |
| 2.1 | Sierra (10.12+) | x64 | More information |
Beginning with macOS Catalina (version 10.15), all software built after June 1, 2019 that is distributed with Developer ID, must be notarized. This requirement applies to the .NET runtime, .NET SDK, and software created with .NET.
The runtime and SDK installers for .NET 5.0 and .NET Core 3.1, 3.0, and 2.1, have been notarized since February 18, 2020. Prior released versions aren't notarized. If you run a non-notarized app, you'll see an error similar to the following image:
For more information about how enforced-notarization affects .NET (and your .NET apps), see Working with macOS Catalina Notarization.
libgdiplus
.NET applications that use the System.Drawing.Common assembly require libgdiplus to be installed.
An easy way to obtain libgdiplus is by using the Homebrew ('brew') package manager for macOS. After installing brew, install libgdiplus by executing the following commands at a Terminal (command) prompt:
Install with an installer
macOS has standalone installers that can be used to install the .NET 5.0 SDK:
Download and manually install
As an alternative to the macOS installers for .NET, you can download and manually install the SDK and runtime. Manual install is usually performed as part of continuous integration testing. For a developer or user, it's generally better to use an installer.
If you install .NET SDK, you don't need to install the corresponding runtime. First, download a binary release for either the SDK or the runtime from one of the following sites:
- ✔️ .NET 5.0 downloads
- ✔️ .NET Core 3.1 downloads
- ✔️ .NET Core 2.1 downloads
Next, extract the downloaded file and use the export command to set variables used by .NET and then ensure .NET is in PATH.
To extract the runtime and make the .NET CLI commands available at the terminal, first download a .NET binary release. Then, open a terminal and run the following commands from the directory where the file was saved. The archive file name may be different depending on what you downloaded.
Use the following commands to extract the runtime or SDK that you downloaded. Remember to change the DOTNET_FILE value to your file name:
Tip
The preceding export commands only make the .NET CLI commands available for the terminal session in which it was run.
You can edit your shell profile to permanently add the commands. There are a number of different shells available for Linux and each has a different profile. For example:
- Bash Shell: ~/.bash_profile, ~/.bashrc
- Korn Shell: ~/.kshrc or .profile
- Z Shell: ~/.zshrc or .zprofile
Edit the appropriate source file for your shell and add :$HOME/dotnet to the end of the existing PATH statement. If no PATH statement is included, add a new line with export PATH=$PATH:$HOME/dotnet.
Also, add export DOTNET_ROOT=$HOME/dotnet to the end of the file.
This approach lets you install different versions into separate locations and choose explicitly which one to use by which application.
Install with Visual Studio for Mac
Visual Studio for Mac installs the .NET SDK when the .NET workload is selected. To get started with .NET development on macOS, see Install Visual Studio 2019 for Mac.
| .NET SDK version | Visual Studio version |
|---|---|
| 5.0 | Visual Studio 2019 for Mac version 8.8 or higher. |
| 3.1 | Visual Studio 2019 for Mac version 8.4 or higher. |
| 2.1 | Visual Studio 2019 for Mac version 8.0 or higher. |
Install alongside Visual Studio Code
Visual Studio Code is a powerful and lightweight source code editor that runs on your desktop. Visual Studio Code is available for Windows, macOS, and Linux.
While Visual Studio Code doesn't come with an automated .NET installer like Visual Studio does, adding .NET support is simple.
- Download and install Visual Studio Code.
- Download and install the .NET SDK.
- Install the C# extension from the Visual Studio Code marketplace.
Install with bash automation
The dotnet-install scripts are used for automation and non-admin installs of the runtime. You can download the script from the dotnet-install script reference page.
The script defaults to installing the latest long term support (LTS) version, which is .NET Core 3.1. You can choose a specific release by specifying the current switch. Include the runtime switch to install a runtime. Otherwise, the script installs the SDK.
Note
The previous command installs the ASP.NET Core runtime for maximum compatability. The ASP.NET Core runtime also includes the standard .NET runtime.
Docker
Containers provide a lightweight way to isolate your application from the rest of the host system. Containers on the same machine share just the kernel and use resources given to your application.
.NET can run in a Docker container. Official .NET Docker images are published to the Microsoft Container Registry (MCR) and are discoverable at the Microsoft .NET Core Docker Hub repository. Each repository contains images for different combinations of the .NET (SDK or Runtime) and OS that you can use.
Microsoft provides images that are tailored for specific scenarios. For example, the ASP.NET Core repository provides images that are built for running ASP.NET Core apps in production.
For more information about using .NET Core in a Docker container, see Introduction to .NET and Docker and Samples.
Next steps
- How to check if .NET Core is already installed.
- Working with macOS Catalina notarization.
- Tutorial: Get started on macOS.
- Tutorial: Create a new app with Visual Studio Code.
- Tutorial: Containerize a .NET Core app.
.NET ToolsHow-To'sVisual Studio For Mac M1 Download
During the last several days, I’ve been experimenting with an Apple M1 device from the perspective of a .NET Developer using a typical developer toolkit: .NET SDKs, Node, JetBrains Rider, other editors, and mobile emulators.
For .NET developers considering using an Apple M1 for their daily development machine, we’ll see what it is currently like to work on these devices. The goal is not to get everything to work, but to share the out-of-the-box experience developers will face in adopting an M1 chipset-driven products.
Apple M1?
On November 1st, 2020, through a mesmerizing drone-driven presentation, Apple unleashed its first chip explicitly designed for its Mac product line. 'Unleash' is an appropriate verb, as with the new chipset, Apple’s claims are to deliver performance and efficiency with no compromises.
M1 delivers up to 3.5x faster CPU performance, up to 6x faster GPU performance, and up to 15x faster machine learning, all while enabling battery life up to 2x longer than previous-generation Macs. — Apple
Apple’s claims are promising from a technical perspective, but what about current real-world usage? One of the current issues facing the transition to M1 is the architectural move from the x86 instruction set to the ARM instruction set. To make the transition smoother for everyone adopting these new devices, Apple has implemented a translation layer called Rosetta 2.
Existing Mac apps that have not been updated to Universal will run seamlessly with Apple’s Rosetta 2 technology. — Apple
Let’s give it a try!
.NET Development
My goal from the onset was to experience what the 'average' developer would. I didn’t compile any special runtimes or have access to unique installers. Any developer out there will have access to the same environmental conditions. All experiences occurred with x86 translation via Rosetta 2.
Generally, .NET development comes in two choices: Mono and .NET Core. Developers can work with the .NET Framework through software development kits (SDKs). During this trial, I tested Mono, .NET Core 2.1, .NET Core 3.1, and .NET 5. All SDKs successfully built multiple solutions, from small sample Hello, World applications to complex OSS solutions.
I built projects primarily in Rider, and by using the .NET CLI from a terminal. From an anecdotal viewpoint, the experience was uneventful, which makes it remarkable. Code completion, package additions, and development functionality just worked. Build times were respectable but were slightly slower than my personal six-core i7 MacBook Pro. 'Slower' is a relative term, and I believe most folks wouldn’t notice this difference as they did their daily work.
Within the .NET ecosytem, there are different development niches, the largest being ASP.NET, a web framework. While testing several web projects, the local development servers could start and service requests as they usually would. Similar to my experience building projects, it was what most developers would expect from a development environment.
Mobile development is another popular focus of .NET developers. The Xamarin SDK included with JetBrains Rider did not work, but a workaround uses the latest SDK version with Visual Studio for Mac, which Rider will recognize. The current master branch of the SDK is broken, but the team is working to address the SDK issue.
During mobile development, I tested targeting Android and iOS devices with the iOS simulators working as expected. The Android emulator would begin to boot, but the device image would not load. During my testing with Android, I attempted both x86 and ARM images with no success. Experienced mobile developers will likely be using physical test devices, so this might not be a deal-breaker.
The biggest issue that might deter .NET developers is the current lack of debugger support for .NET Core SDK solutions. None of the major .NET editors could attach the debugger to a running process. The attempt to do so would throw a StackOverflowException. Exceptions seem to originate from the kernel with a C method named thread_set_state.
Not surprisingly, the debugger shipped with the Mono SDK runs without issue. Mono is designed to run C# on iOS and Android devices natively. Apple and OSS authors of Mono likely resolved issues facing the Mono runtime before Apple Silicon’s official launch.
Developers focusing on Xamarin, which still uses Mono, should have no debugging issues. While not tested, Unity game developers also use Mono, and I assume that will work as well. All promises of reliability are up in the air for Mono devs utilizing P/Invoke calls down to native system calls. Folks will need to test native system calls on a need-by-need basis.
The .NET team has efforts to make .NET 5 compatible with Rossetta 2. Native support is a goal for .NET 6, with planning already starting.
Visual Studio For Mac M1 Key
For folks interested in performance, developer Hank G. has done extensive benchmarking utilizing .NET Runtime test harnesses. Hank G. found the Intel chips outperformed the M1 in some cases. In other instances, the opposite occurred. It’s important to keep in mind that the M1 chipset delivers an enjoyable performance experience at almost half the cost of its MacBook Pro predecessors. The mere fact that it can keep up in benchmarks in an unoptimized state is impressive alone. Few will notice the differences between M1 and Intel for daily usage, even during this Rosetta 2 period.
Thoughts around .NET focused development on an M1 device are generally positive. The development time experience of writing and compiling code is uneventful and yawn-inducing (in the right way – it 'just works'!). Developers uncomfortable with bleeding-edge pain will likely think twice before purchasing an M1 device, that is unless minor releases of the SDKs address the debugger issues. Current Xamarin and Unity developers still using Mono will have an overall experience that works.
I’ve focused on .NET, but no one programs in a vacuum… What about dependencies?
Dependencies
Containerization has become a popular way of utilizing external dependencies, and Docker is the de-facto way many developers consume databases, cache providers, and more. Sadly, as of writing this post, Docker doesn’t yet work on the M1 chipset. There are always workarounds:
- Install dependencies locally on the host machine.
- Use remote devices or cloud services.
- Other virtualization approaches on the host.
These workarounds have their drawbacks, like network latency, excessive local resource utilization, general upkeep that containers don’t suffer from, but it does get developers working.
Docker has a preview build that supports Apple Silicon and is currently available to folks in the developer preview program. That said, .NET developers will likely struggle to find ARM container images for current dependencies like SQL Server for Linux or the .NET runtime itself. It’s important to remember how Docker containers work. They utilize calls to the host operating system, so calls need to use the ARM instruction set both inside and outside of containers. Since virtualization is occuring, Rosetta 2 cannot convert x86 containers to run on Apple Silicon.
Docker running on Apple Silicon is only the first step in supporting containerization enabled workflows. Solution vendors will need to build images that utilize ARM instruction sets.
Visual Studio For Mac M1 Download
Node
As .NET developers, we also have a reliance on the JavaScript ecosystem to deliver frontend experiences. I’m happy to report that Node seems to work, with NPM packages generally working. There are known node packages that rely on native compilation which may not work, but in my testing I was not able to find an issue. I built and ran our JetBrains Guide Gatsby project with no issues. The project utilizes many dependencies, including Yarn, another package management system.
Conclusion
Visual Studio For Mac M1 Free
Overall, I had a positive experience programming .NET on an M1 device. Apart from the .NET debugging issue and Docker currently not working, it’s impressive that almost everything seems to just work with Rosetta 2! And keep in mind, it’s not a matter of if there will come native support for specific development scenarios and .NET; it’s only a matter of when.