Turns out, the hysteria around it was exaggerated, Apple addressed the issue in a later update to Big Sur.

For reference, I’ve been using this MacBook Air M1 for over a year now, I’ve basically transferred all of my Development workflow onto it and these are my stats:

When inspecting my workflow, you’ll see that I’m maxing out the memory (16GB) on a daily basis, but for the moment, it does not result in any excessive wear to the SSD.

Although I wouldn’t recommend less than 16GB for Software Development, I get by just fine, for now.

As for performance, the M1 packs more than enough horsepower for my daily workloads, so I’m not too worried.

Eagerly waiting for that M2, though… 🤪🤩

In closing

Earlier this year, Hector Martin pointed out that, essentially, the “data” that is supposed to be on disk is kept in memory for longer than expected. Meaning, MacOs can cheat its way into performing faster than other systems. So if your device would be to lose power, even when idle, it could result in data loss.

This isn’t an issue for MacBooks persé, but it sure makes you wonder about the iMac and Mac mini and even, the new Mac Studio Desktop.

While I’m sure Apple will address these issues at some point in the future, it seems consumers need to be wary of this situation.

We’re excited to announce that Prise has been successfully ported to .NET 6, thanks to https://github.com/tartanlegrand for the Pull Request!

In this version, the framework has been upgraded to net6.0, at this point, we’re not planning to add any additional features to Prise. We are planning to release an update to the Visual Studio Publish Plugin Extension for Visual Studio 2022, this is currently being worked on and will release before the end of the year.

It’s lovely to see that Prise is growing slowly, while the numbers are not mind-blowing, we still are proud to see that our hard work is being consumed.

For those who are still unfamiliar with Prise, Prise is a .NET (Core) plugin framework that allows you to truly write a plugin once and inject it forever into your application, due to its guaranteed backwards plugin compatibility.

Check out our documentation guide: https://merken.github.io/Prise

Check out the example Weather application: https://github.com/merken/Weather

Hope to see you in 2022, cheers!

I switched to a MacBook about 2 years ago, I’m a Software Engineer in .NET and Angular.

Since .NET (Core) is cross-platform, I decided to switch things up a bit, and once Apple introduced their new in-house ARM-based silicon, I was eager to try it out.

This is how I managed to setup my M1 MacBook Air for .NET and Angular (NodeJS) development.

The state of .NET on Apple ARM64

When the M1 chip came out, it was already possible to install the runtime (or even the SDK) of .NET Core 3.1 (and lower) and have it compile and run applications. This just worked using Rosetta:

dotnet myapp.dll

Debugging, however, was an entire different story. The dotnet team and Apple were in close contact in order to smooth out bugs in Rosetta. You could join the Big Sur beta program in order to get these fixes early on.

The latest Big Sur release fully supports running and debugging .NET Core applications (including .NET 5). The performance of .NET under Rosetta was impressive, but it wasn’t orders of magnitude faster than running on Intel.

With .NET 6 on ARM, however, we can see significant improvements in application startup times, ASP.NET response times and general test execution times overall.

When the M1 first came out, Youtuber Alexander Ziskind did a comparison between .NET 5 on Intel vs M1

The Intel i9 MBP outperformed the M1 by a small margin, keep in mind that .NET 5 was running through Rosetta translation.

I retried this test on my M1 using .NET 6 on ARM and these are the results:

47 seconds consistently, not bad considering that the i9 did about 57 seconds and the M1 did about 60 seconds (using Rosetta).

For those who are interested in the benchmarking code, here’s the C# 10 variant of it:

using System.Runtime.CompilerServices;

using System.Security.Cryptography;

for (int i = 0; i < 100_000_000; i++)

{

    Consume(CryptoConfig.CreateFromName("RSA"));

}

[MethodImpl(MethodImplOptions.NoInlining)]

static void Consume<T>(in T _) { }

So, if your workflow exists of pure .NET Core, or .NET 5 or 6, you’ll be happy using your M1 machine for development.

IDE: Integrated Development Environment

When the M1 first came out, most of our toolset relied on the Rosetta 2 translation layer in order to run x86-based applications on the ARM architecture.

This included VS Code, Visual Studio for Mac, JetBrains Rider, Omnisharp, Mono…

The experience was awful on all of them, they’d get the job done eventually, but I wasn’t ready to retire my i7 MacBook Pro anytime soon.

The ARM-based versions of these IDE’s came out gradually, apart from Visual Studio for Mac, all of my workflow can now be run on Apple Silicon natively.

So what’s the status quo for .NET development on M1 in November 2021?

Visual Studio for Mac

I mean, it works?

To understand where Visual Studio for Mac came from, you must first understand MonoDevelop. MonoDevelop is a cross platform IDE for building .NET applications using the Mono framework. It has been around for some time. Visual Studio for Mac is a spin-off this technology. Since there are no plans from Microsoft to port this to native Apple Silicon (ARM64), you’re stuck with Rosetta emulation.

I’ve tried my best to use Visual Studio for Mac, I really did. For small projects, sure, you could give it a shot. But for my 40+ project solution, it just was not performant enough.

However, do not fret, for support on M1 is coming in the future, stay tuned!

VS Code

VS Code was the first IDE to be ported to ARM64 Apple Silicon, mostly due to it was already ported to Raspberry Pi ARM.

You can get the Apple Silicon optimised version of VS Code today. Most of the extensions have been ported to ARM64 and most of all, Omnisharp has been ported to darwin-arm64, too!

VS Code is the best free alternative to develop .NET applications on Apple Silicon. However, VS Code is a code editor, a very capable one. But for professional development you might need an actual IDE.

JetBrains Rider

Let me be blunt, Rider is the best cross-platform IDE for .NET development to date.

Even on Rosetta emulation, Rider was far more performant than Visual Studio for Mac. They were prompt to adopt Apple Silicon, releasing an EAP (early access preview) free of charge in order to test out Rider running natively on ARM64.

Tip: if you want to download the most stable build of Rider, add the following to the download URL : ‘-aarch64.dmg’.

For example: https://download.jetbrains.com/rider/JetBrains.Rider-2021.2.2-aarch64.dmg

If you just want to try out Rider, you can get the EAP version here: https://www.jetbrains.com/rider/nextversion/

Select the Apple Silicon version to download.

This version of Rider comes with its own version of .NET 6 for ARM, you can still install other .NET Core sdks on your system (like .NET Core 3.1). This will run under Rosetta when debugging, Rider is capable of spawning, attaching and terminating these processes, making this the most flexible IDE for .NET Core development to date!

Virtualisation and Emulation: Windows on ARM

Sometimes, as .NET developer, you just need to run a Windows executable on macOS.

For instance, my workflow contains of running an old x86 executable that was built years ago on Windows. This executable is used throughout the company to transform a file from a legacy format into an xml-based format. Many teams use this executable and is has not been modified for years. Porting it to .NET Core was out of scope.

VirtualBox

At the moment, there’s no support to run a Virtual Machine through VirtualBox.

VMWare

VMWare announced a preview version of VMWare Fusion, this allows you to run an ARM-based Virtual Machine. There are some limitations, though. For instance, you can’t get shared networking or shared clipboard to work due to the lack of VMWare Tools for ARM.

UTM

UTM is emulation software and runs on top of QEMU.

Link to tutorial: https://jensd.be/1533/windows/windows-11-arm-on-m1-based-macs-with-utm

Parallels

Parallels is paid software, but in my opinion, it is worth the money if you need a Windows Virtual Machine on macOS. The performance is industry leading and the integration with macOS is sublime. I encourage you to install the trial and see for yourself.

Windows on ARM

Once you’ve picked your virtualisation software above, you’re ready to start with Windows on ARM. Download the Insider Preview from Microsoft and use that virtual hard disk as the starting point for your VM.

After installing Windows 11 on ARM, you may want to activate it, you can do this with any valid Windows 10 license key. But first, make sure all your required software runs smoothly!

x86 applications are emulated on Windows on ARM, so you could technically install Visual Studio for Windows, .NET Framework 3.5 or 4.7, and start developing your WPF applications on that VM. I’ve done this, it works, but it’s not performant. However, I mean, if you occasionally need to handle this kind of workflow, sure, you could give it a shot.

The bottom line is, do not get a Mac for Windows WPF or .NET Framework development.

What about running a x86 Virtual Machine under emulation?

I tried this, using UTM and QEMU, the experience is not pretty. I can’t recommend this approach to anyone.

Docker

Docker (containerisation) is one the most versatile tools and skill you can learn in this decade, so you’ll be happy to hear that this just works on your Apple M1 machine.

Running ARM-based Linux containers

There’s lots of ARM64-based images on Docker hub, mostly thanks to the Raspberry-pi community. Running these containers just work on the M1.

Running x86-based Linux containers

Most of the official docker images are supported to run under AMD64 emulation. This is basically Docker emulating (using QEMU) the container on ARM64.

For instance, if you’d like to run the MySQL x86_64 image on your M1 you’d use:

docker run --platform linux/amd64 mysql/mysql-server:latest

This will spin up a MySQL server container using emulation.

Performance may vary, but when possible, try to find an ARM64 based counterpart for this image, if you can find any.

For MySQL, this is MariaDB

For MSSQL server, this is Azure-Sql-Edge

Running Windows containers

You need a Windows host for this, I do not recommend nested virtualisation, like Parallels, for this. If your workflow requires you to spin up these kind of containers, you’re out of luck on Apple Silicon.

Memory usage and Swap

You might have heard that these M1 ARM chips have got some serious swapping going on, turns out that macOS itself loves to use swap, even if there’s still enough free RAM available.

Turns out, this was nothing to worry about, since Apple fixed these swapping issues update after update.

If you do worry about swap and the lifetime of your SSD. I’d say, skip out on the M1 MAX and invest in RAM first, and SSD second when getting a new M1 MacBook Pro.

Also, try to avoid using apps that require Rosetta translation, this will reduce swap dramatically.

In closing

I’ve been using my M1 MacBook Air with 16GB RAM for over a year now, it has lately replaced my 16" MacBook Pro 2019 i7 5300M 32GB RAM. I enjoy the aesthetics of the Air and mostly the portability, whilst matching, sometimes excelling the performance of the Intel-based machine. For the moment I get by using 16GB of RAM. Once this falls short, I’ll look into getting an M1 Pro.

Azure Bicep is increasing popularity presently, we started adopting this new DSL for Azure ARM some months ago and we have now completely switched over to using Bicep in favour of ARM-based templates.

After installing the Azure ARM and Bicep extensions on an M1 Mac you might see the following errors:

The fix is two-fold, you need to install both the 3.1 and 5.0 dotnet runtime on your machine using a Rosetta Terminal, and you need to configure the extension to use that runtime installation

Rosetta Terminal

If you don’t have a Rosetta Terminal yet, you can make one yourself by copying the Terminal.app from the Applications/Utilities directory.

Select Terminal.app

⌘ + C

⌘ + V

After copying, rename the new Terminal.app to Rosetta Terminal.app

Right-click the Rosetta Terminal.app and select Get Info.

Select the checkbox Open using Rosetta

Close the information window.

Installing the dotnet runtimes using Rosetta Terminal

Launch the new Rosetta Terminal.app

Open an ARM template file in VS Code, you will see the following error:

Select the .NET Runtime output stream.

Select the installer command that this extension tried to execute:

Paste and run the command you selected above in your Rosetta Terminal.app.

Open a Bicep file and your should get the same error on the dotnet 5.0 runtime…

Repeat the previous steps, select the command from the output window and paste inside the Rosetta Terminal.app.

Configuring the extensions

Now we need to configure these extensions to use the correct dotnet command.

Open VS Code.

Press ⌘ + SHIFT +P and type ‘Open settings’, select the Open Settings (JSON) option:

Add the following to your settings.json file:

"dotnetAcquisitionExtension.existingDotnetPath": [

    {

         "extensionId": "msazurermtools.azurerm-vscode-tools",

         "path": "/usr/local/share/dotnet/dotnet"

    },

    {

        "extensionId": "ms-azuretools.vscode-bicep",

        "path": "/usr/local/share/dotnet/dotnet"

    }

]

Save and reload, you should be able to launch the ARM Template and Bicep Language Server now!

Apple M1 + VS Code: ARM Template and Template Language Service was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

About 2 years ago, I wrote on how to run SQL Express in a Docker container using the Microsoft SQL Server for Linux Docker image.

Now, I find myself in need for the same on my M1 Mac. The original SQL Server for Linux image has not yet been ported to the ARM64 architecture. However, I found that there’s a new database technology, targeted for AI named Azure SQL Edge. This database has been Dockerised and ported to ARM64 and thus can run on Docker for M1 on your Mac.

TL;RD; This is how to run a Docker SQL instance on M1:

docker run -e "ACCEPT_EULA=1" -e "MSSQL_SA_PASSWORD=MyPass@word" -e "MSSQL_PID=Developer" -e "MSSQL_USER=SA" -p 1433:1433 -d --name=sql mcr.microsoft.com/azure-sql-edge

Docker for M1

Docker for M1 has come a long way since late 2020, the Docker team’s effort shines in the latest RC version for ARM64, which can be found here. You will need to have this latest version (or later) installed to run the SQL container successfully. After installation, run the script mentioned above.

Connecting via Azure Data Studio

To connect via Azure Data Studio, you will need to put 127.0.0.1 as server, we’re already hosting the Docker container on port 1433, which is the default port for SQL. Use SQL Login and set the user to sa. Lastly, set the password you chose, which was MyPass@word from the example above.

Hit Connect and see if that works! If you have any issues connecting, maybe check to see if the container is actually running:

docker ps

If not, try starting it manually:

docker run sql

Creating a database

I recommend not to use the master database and simply just create your own, run the following in a New Query window in Azure Data Studio:

USE master

GO

IF NOT EXISTS (SELECT [name]

FROM sys.databases

WHERE [name] = N'TestDb')

CREATE DATABASE TestDb

GO

This script will create a database named TestDb, if it doesn’t exist already.

After running this script, you should see that new TestDb in the list of databases:

Be sure to select the correct database in the dropdown when running any query from now on!

Inserting data

Now let us put this to the test and insert some data. The script below will create a table, insert one record and select that record from the newly created table:

CREATE TABLE MyDto(

Number INT,

Text NVARCHAR(255)

)

GO

INSERT INTO MyDto VALUES (1, 'This is from my M1 Mac!')

GO

SELECT * FROM MyDto

That’s it! We now have a functional SQL Docker container on Apple Silicon!

Docker Express: Running a Local SQL Server on Your M1 Mac was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

I found myself in need of quickly converting my C# Console application into a Web application, primarily, I was asked to expose our Console app’s logic through an API with very little time to manage it.

This article will cover on how I eventually exposed our Console app on port 5005 of the localhost, our internal network, for bonus, I’ll throw in the containerised Docker version of the app, too!

Let’s start with a simple console app:

mkdir ConsoleToWeb
cd ConsoleToWeb
dotnet new console
dotnet run

The source of this app will look something like this:

To convert this into a ASP.NET Web App, we need to do 3 things:

• Convert the console project into a web project (csproj)
• Introduce a Generic Host to host our Web App
• Rewrite the Main method to run our WebHost

Converting a Console csproj into a Web csproj

Our original Console csproj looks something like the following:

For a Web project, we need to target a different SDK; Microsoft.NET.Sdk.Web

Also, the OutputType does not need to be an Exe.

Modify the csproj file to look like this:

Introduce a Generic Host to host our Web App

The IHost class is a class designed for the new app hosting system of .NET. It handles core functionality like Dependency Injection, Configuration, Logging, …

We will use the HostBuilder to create a vanilla Web Host that will have 1 Run method which will call the code from our Console app.

Add the following code to your Program.cs file:

Don’t forget about the necessary using statements:

using Microsoft.Extensions.Hosting;

using Microsoft.AspNetCore.Builder;

using Microsoft.AspNetCore.Hosting;

using Microsoft.AspNetCore.Http;

Rewrite the Main method to run our WebHost

We’re almost there, we just need to tie it all up in the Main method of the Program.cs:

Let’s examine the full working example:

That is it! Now you can run the app using dotnet run and see the result in your browser at http://localhost:5005

Dockerize it!

Since we’re on a roll here, let’s quickly Dockerize this app so that we can package and ship it.

Add a Dockerfile to the root of the ConsoleToWeb directory.

touch Dockerfile

The contents of the Dockerfile should be something like:

Now that is done, we can build our image locally and tag it:

docker build . -t consoletoweb

After the Docker image is built, we can run the image in a container using docker run -p 5005:5005 consoletoweb

And the effect should be the same on http://localhost:5005

Quickly adding services using FuncR

Still going strong now, let’s introduce a service, add some small implementation and have that service injected into our Web App using Dependency Injection!

Introduce the IFooService:

Now, we could implement this service using a new class, or we could write just the code we need for string Foo(int numberOfFoos) method to work using a function with FuncR.

FuncR is a small .NET standard library that enables you to register functions against interfaces in C#.

First we need to add FuncR to the project

dotnet add package FuncR

To use FuncR, add a ConfigureServices method to your Program.cs file:

In this ConfigureServices method, you can register any service agains the DI container of ASP.NET, more concretely, the code above registers a Proxy for IFooService and hooks up the string Foo(int numberOfFoos) method to the function that is provided on lines 7 and 8, cool huh!?

Now we just need to tell the HostBuilder to use this method to configure its services and we’re ready to have that service injected:

If we now dotnet run and navigate to http://localhost:5005 we finally see some different output:

That’s a lot of Foo’s.

And naturally, the Docker example also still works after a rebuild and run:

docker build . --no-cache -t consoletoweb
docker run -p 5005:5005 consoletoweb

Wrapping up

In this article we saw how easy and quickly a console app can be converted into a ASP.NET web app, and we got an introduction to FuncR to speed up our service implementations. The full code, and more is available through GitHub:

https://github.com/merken/ConsoleToWeb

Quickly Convert a Console App Into a Single-Point Web App in C# was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is mostly the case when working with code that communicates with infrastructure (logging, files, network, API’s). This code is mostly static and does not require a whole new service implementation. But, nevertheless a new class needs to becreated to hold this functionality.

I started looking for the most concise form of writing that functionality, without the need of introducing a new service implementation class, an interface to a function, sort of speak…

The result of this work has been packaged into a small library called FuncR, allow me to elaborate…

FuncR is a small .NET standard library that enables you to register functions against interfaces in C#.

In short, it allows you to go from this:

Into something like this:

FuncR uses a DispatchProxy to generate a proxy class that instantiates the interface at runtime and hooks up the registered functions to the interface methods.

This allows you to inject the interface into your services and use it like any other service in your domain.

Let’s put this all together inside a .NET console app!

Create a new Console app (in .NET Core 2, 3 or .NET 5):

mkdir Your.First.Function
cd Your.First.Function
dotnet new console

Add the FuncR package:

dotnet add package FuncR

Write the implementation:

Run the implementation:

dotnet run

Details of the example

Line #8 sets up the stage for our service interface.

Line #19 registers the proxy for IFooService

Line #20 registers the function pointer for the name “Foo” on the proxy

Lines #22-28 registers the actual implementation of the function for the proxy in the form of <TParameter1Type, TReturnType>, like any C# Func

Line #30 resolves our registered service from the Dependency Injection container.

Lines #34 and #36 call upon the proxy, which will look up the registered function and invoke it.

📚Documentation

FuncR comes with extensive documentation and sample projects to help you get started!

This includes, service resolution through dependency injection, async functions and nested functions.

C#: Interfaces to Functions, With FuncR was originally published in Geek Culture on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this short article, I’ll show you how to uninstall any previous dotnet versions on your M1 Mac and install the latest .NET 6.0.200 Preview release to date.

Microsoft released the official ARM64 macOS installer, please refer to this installer to install the .NET 6 Preview 3. You can continue reading to find out how to install the .NET SDK manually.

Earlier, I wrote about debugging .NET 5 apps on your M1 Mac using the Rosetta 2 translation on macOS Big Sur 11.2 Beta 2. Now, I’m going to show you how to install the latest .NET 6 build onto your M1 Mac.

Firstly, to avoid conflict, remove all .NET installations from your machine, this is easily done using the dotnet-uninstall-pkgs script found here: https://github.com/dotnet/cli/blob/master/scripts/obtain/uninstall/dotnet-uninstall-pkgs.sh

After downloading this file, make it executable so that you can execute it:

cd ~/Downloads
sudo chmod +x dotnet-uninstall-pkgs.sh
sudo ./dotnet-uninstall-pkgs.sh

After uninstall, verify that all dotnet installations are removed:

dotnet
where dotnet

Download the .NET 6 Alpha 6.0.100 release from here : https://github.com/dotnet/installer

Or via direct download to the latest version: https://aka.ms/dotnet/6.0/daily/dotnet-sdk-osx-arm64.tar.gz

Installing .NET 6 to /usr/local/share/dotnet

dotnet installs to /usr/local/share/dotnet when using the pkgs installer, so that’s what we’re going to do also.

Extract the tar.gz file to disk and examine the contents:

Copy all files to /usr/local/share/dotnet:

cd <net-6 directory>
cp -a . /usr/local/share/dotnet

Whitelisting all files from /usr/local/share/dotnet from Apple Quarantine

When you try to run the dotnet command in your terminal, you will be prompted to allow the execution for each library that the command invokes.

To avoid this for all files within the /usr/local/share/dotnet directory, you will need to run the following command in terminal:

find . -type f -print0 | xargs -0 xattr -d com.apple.quarantine

After this, you need to create a symbolic link to the /usr/local/share/dotnet/dotnet executable.

cd /usr/local/bin
ln -s /usr/local/share/dotnet/dotnet dotnet

At this point, you can use the dotnet command anywhere on your system.

Performance

Alexander Ziskind did a performance comparison between the M1 Macbook Air and the Intel i9 Macbook Pro 16, which you can find here.

I noticed that .NET 6, running natively on the MBA, performs a bit better when running his example cryptography application for 100.000.000 iterations.

using System;
using System.Runtime.CompilerServices;
using System.Security.Cryptography;

namespace ziskindtest
{
    class Program
    {
        static void Main(string[] args)
        {
            for (int i = 0; i < 100_000_000; i++)
            {
                Consume(CryptoConfig.CreateFromName("RSA"));
            }
            Console.WriteLine("All done MBA on .NET6");
        }

        [MethodImpl(MethodImplOptions.NoInlining)]
        private static void Consume<T>(in T _) { }
    }
}

The results on my M1 MBA were promising, it beats the results from the beefy i9 by a slight margin, I ran a dotnet build -c Release and dotnet run of the published app, and it persisted to run the test in around 53 seconds, which looks like it’s not that big of a performance gain over the 60 seconds running on Rosetta 2.

Then again, this is .NET 6 Alpha running on macOS Beta…

It’s still impressive that the M1 chip is able to compete against top-of-the-line Intel processors.

What this tells me is that Rosetta 2, truly is an example of magnificent engineering.

Removing the manually installed dotnet 6 Alpha

Undoing this installation is quite easy, you just need to delete the /usr/local/share/dotnet directory and the dotnet symbolic link at /usr/local/bin.

rm -rf /usr/local/share/dotnet
rm /usr/local/bin/dotnet

In this short article, I’ll show you how to install .NET 5 on your M1 Mac and demonstrate how to debug your apps using VS Code and VS For Mac.

With macOS Big Sur 11.2 Beta 2, Apple fixed some of the bugs related to debugging your .NET 5 apps on M1 Macs, this allows you to debug .NET applications using VS Code, VS for Mac and even JetBrains Rider through the Rosetta 2 x86-to-ARM translator.

First, your Mac needs to be enrolled into the Beta program. This requires registering your Apple ID and downloading a tool that gives you access to beta builds of Big Sur. After installing that, your M1 Mac should be able to search for updates, on which you should get 11.2 Beta 2.

After installing the beta, download .NET 5 from the official website (macOS, x64).

You should now be able to run and debug .NET 5 apps on you M1 machine.

^ This also works with VS Code insiders built for M1!

Keep in mind that Beta means Beta. There are some cases on which the debugger crashes, let’s hope the stable release of Big Sur 11.2 addresses these issues.

Over the past year, I’ve been working on maturing Prise. I can proudly say that the day has come to announce version 2.0 of Prise, A .NET Plugin Framework.

This time around, I’ve heard the community loud and clear 📢, Prise comes with the following new features:

• More tests!
• Support for testing plugins using the Prise.Testing package
• Rename of the PluginBridge to ReverseProxy
• Support for loading plugins from NuGet Packages!
• More examples!
• A fresh new documentation page: https://merken.github.io/Prise/

Whilst still working on supporting .NET 5, Prise can presently be used in any .NET Core 2.1, 3.1 or NET 5 preview project.