It’s been a while since we’ve talked about the preview releases coming from the .NET Team. Mostly that’s been because many of the preview updates contain small incremental releases that aren’t quite anything to write home about yet. For example, if you’re not interested or using Blazor at the moment, then three quarters of the updates aren’t for you.

But that changes with .NET 7 Preview 6 release with two new features that are going to be all out game changers. Those are :

  • Output caching middleware
  • Rate limiting middleware

I’ll chat about both of these, but first, how can you get your hands on them yourself?

Downloading .NET 7 Preview 6

The first thing you should do is download the preview SDK from here.

Next is a little tricky. If you are using Visual Studio Code, then you *should* be able to get things running immediately. However, for Visual Studio, you will need the preview version available here.

Again, I want to reiterate that you need the preview version of Visual Studio 2022. You cannot use any previous versions of Visual Studio (e.g. 2019), nor can you use the release version.

Output Caching Middleware

When this gets a general release, we’ll dive into it more thoroughly, but for now, I actually just wanted to talk about one feature that the more I thought about, the more I realized “I can’t believe this hasn’t been solved in the past”.

Think about a scenario whereby an extremely popular API endpoint gets called multiple times per second. That endpoint calls a database stored procedure which itself takes several seconds to complete (That’s why we’re caching it after all!).

Let’s say we invalidate that cache at some point. Typically every request will now hit the endpoint, and execute the stored procedure all at the same time. We can call this “cache stampedes”, whereby the check is simply “No cache?, go to the database”.

.NET however has a solution for this. Instead of every request calling the database until the first result is returned, it will instead allow the very first request to call the database, and all subsequent requests will instead wait for the cache to be populated. It’s something so simple, yet also something I’ve seen in production a lot.

Even if you remove the cache invalidation, I’ve often see deployments go belly up because the cache isn’t “pre-primed” before go live. This solution from the .NET Team also solves this!

So what complex code do you need to set this up? Well.. Just a single line of course :

app.MapGet("/myendpoint", () => DoWork()).CacheOutput();

Rate Limiting Middleware

Similar to the Output Caching Middleware, a Rate Limiting Middleware is well overdue as a first class citizen in the .NET ecosystem.

I think we all have the concept of rate limiting in general, but what took my interest in this, was that the .NET Team have implemented various types of rate limits and packaged them all into the same middleware. That is, you now have many strategies in which you can rate limit your application rather than a simple “X requests in X timespan”.

Already announced are :

Concurrent Request Limit

Does what it says on the tin. If your concurrent limit is 5 requests, then there can only be 5 requests being processed at one time (And the 6th will be rejected). As soon as one of those 5 completes, a new request can be made.

Token Bucket Limit

Imagine a bucket that can hold 100 tokens. And every minute, 10 tokens are added back into the bucket. When a request comes in, a token is removed from the bucket, and so on. This type of strategy is very common when you need some sort of burstability because you can completely drain the bucket all at once if you wish, and then wait for the tokens to slowly fill up again.

Fixed Window Limit

Put simply, every hour you can make 100 requests. Every hour, this limit resets back to 100. Nice and simple! This is extremely useful if you have “daily” limits for example where the limit is tied to a particular time e.x. At midnight the rate limit resets.

Sliding Window Limit

Similar to the fixed window limit, you can make 100 requests in any 1 hour window, but that 1 hour window moves. More or less, the strategy becomes “In the past hour, you may have no more than 100 requests”.

Join over 3,000 subscribers who are receiving our weekly post digest, a roundup of this weeks blog posts.
We hate spam. Your email address will not be sold or shared with anyone else.

This past week, NET 7 Preview 1 was released! By extension, this also means that Entity Framework 7 and ASP.NET Core 7 preview versions shipped at the same time.

So what’s new? In all honesty not a heck of a lot that will blow your mind! As with most Preview 1 releases, it’s mostly about getting that first version bump out of the way and any major blockers from the previous release sorted. So with that in mind, skimming the release notes I can see :

  • Progress continues on MAUI (The multi platform UI components for .NET), but we are still not at an RC (Although RC should be shipping with .NET 7)
  • Entity Framework changes are almost entirely bugs from the previous release
  • There is a slight push (And I’ve also seen this on Twitter), to merge in concepts from Orleans, or more broadly, having .NET 7 focus on quality of life improvements that lend itself to microservices or independent distributed applications (Expect to hear more about this as we get closer to .NET 7 release)
  • Further support for nullable reference types in various .NET libraries
  • Further support for file uploads and streams when building API’s using the Minimal API framework
  • Support for nullable reference types in MVC Views/Razor Pages
  • Performance improvements for header parsing in web applications

So nothing too ground breaking here. Importantly .NET 7 is labelled as a “Current” release which means it only receives 18 months of support. This is normal as Microsoft tend to alternate releases between Life Time Support and Current.

You can download .NET 7 Preview 1 here :

And you will require Visual Studio 2022 *Preview*!

Join over 3,000 subscribers who are receiving our weekly post digest, a roundup of this weeks blog posts.
We hate spam. Your email address will not be sold or shared with anyone else.

TL;DR; Check out the new Q&A Section here :

It’s almost 5 years to the day that I started .NET Core Tutorials. I actually went back and checked and the first ever post was on the 26th of December. Maybe that gives away just how much I do xmas!

One of the first things I did all those years ago was set up an email (, and start fielding questions from people. After all, my writing was literally just me figuring things out as I tried to get to grips on the differences between .NET Core and .NET Framework. Over the years, I’ve probably had an ungodly amount of emails from students to 30 year veterans, just asking questions about .NET and C# in general. Some were clearly homework questions, and others were about bugs in .NET Core that I had a hell of a time debugging, but I treated them all the same and gave replies as best I could.

Some of those questions got turned into blog posts of their own where I more or less shared my reply. But other times, the answer was simple enough that dedicating an entire post to what was almost a one word answer or a 5 line code snippet seemed somewhat dumb. That being said, it always annoyed me that while I was willing to help anyone and everyone who emailed me, me replying to that person one on one and not sharing it wasn’t helping anyone else at the same time.

So, with a bit of time on my hands I’ve spun up a Q&A section right here :

What are the rules? Well.. I’m not really sure. For now, I’m just slowing going back and posting questions that I have been emailed over the years, and pasting in my answer to the question. But *anyone* is available to post a question (You don’t even have to register/login), and *anyone* can post an answer, even on questions that already have answers. I know it’s a bit redundant when things like stackoverflow exist, but again, I’m just trying to share what can’t be turned into it’s own fully fledged post.

Will it be overrun with spam in 3 months time? Who knows. But for now, feel free to jump in, post a question, lend a helping hand with an answer, and let’s see how we go.

Join over 3,000 subscribers who are receiving our weekly post digest, a roundup of this weeks blog posts.
We hate spam. Your email address will not be sold or shared with anyone else.

.NET 6 has reached General Availability as of today! That means what’s in is in, and what’s out is out. You can go grab the latest SDK/Runtime from right here :

The official release post is available here :

But of course, I’ll jot down some of the more important cliff notes!

  • .NET 6 also includes a myriad of changes to C# 10, many of which are outlined in a previous post here :
  • Visual Studio 2022 has also been released and is available here :
  • ASP.NET Core also gets a new release with it’s own announcement here :
  • .NET 6 is a LTS, that means 3 years of support. This may not sound much but it is important. .NET 3.0 for example was not LTS and was only supported for 6 months (insane for a major version number if you ask me but anyway…)
  • Hot Reload has made it into both Visual Studio 2022 *and* the CLI (For why the CLI is important, see here :
  • .NET MAUI *did not* make it into .NET 6 (Even though many posts reference this). MAUI stands for “Multi Platform App UI”. Essentially the next cross platform UI for mobile and desktop (Xamarin style). Unfortunately I think the team bit off a little more than they could chew, so this will be coming a bit later.
  • Azure Functions (If that’s your thing) supports .NET 6 same day. This is actually huge because Azure Functions did not support .NET 5 (Ugh, don’t ask!).

All in all, a pretty solid release going forward. .NET Releases for a while have had little tag lines, and .NET 6 has “The Fastest .NET Yet”. I would say that that’s been an ongoing trend from the .NET team where each release has gotten little tune ups along the way. I’m going to be writing a bit more in the future about some of the lesser known features (For example, Single File Apps got a massive upgrade recently!), but until then dive in and have a peek yourself!

Join over 3,000 subscribers who are receiving our weekly post digest, a roundup of this weeks blog posts.
We hate spam. Your email address will not be sold or shared with anyone else.

Want to learn more about Hot Reload? Check out the quick intro here :

There’s been a bit of a hoopla lately around Microsoft pulling a feature from the upcoming .NET 6 release. The feature in question is “Hot Reload”. I’m going to do a post in the future that goes more in depth as to what hot reload can and can’t do, but it’s pretty darn impressive and works in ways you actually don’t expect it to.

The cliff notes for what hot reload does is that it allows you to apply code changes to a running application *without* recompiling and restarting the application. If you’ve used the dotnet watch command before, it’s similar, expect that with dotnet watch it recompiles the entire application and restarts. Hot reload literally applies the changes right there and then as the application is running.

To give you an idea of just how bananas this is, here’s a gif of a console application below. I have it outputting “ABC” every 1 second. I then go ahead and change the text output, and hit the Hot Reload button on the toolbar and without the application closing, my changes are applied in realtime without skipping a bit. Pretty incredible!

(Click to view the full size GIF)

So, amazing feature, works well, what’s all the kerfuffle about?

It all started with the following blog post :

Most notably this quote :

With these considerations, we’ve decided that starting with the upcoming .NET 6 GA release, we will enable Hot Reload functionality only through Visual Studio 2022 so we can focus on providing the best experiences to the most users. We’ll also continue to pursue adding Hot Reload to Visual Studio for Mac in a future release. […] To clarify, we are not releasing Hot Reload as a feature of the dotnet watch tool

What Microsoft is saying here is that the hot reload functionality will be only available through Visual Studio 2022, not via Command Line, Visual Studio For Mac or VS Code. At first, this doesn’t seem like such a big deal right? A feature has been built for Visual Studio and not for anything else. It happens.

But there’s a problem. It actually does exist on the command line for preview versions of .NET 6, but this PR removes the feature : So what we’re seeing is that Microsoft actively pulled a feature to make it available only in Visual Studio, and not on any other platform.

It’s also somewhat doubly annoying because back in May, the support for hot reload via dotnet watch was actually announced itself in a blog post :

Today, we are excited to introduce you to the availability of the .NET Hot Reload experience in Visual Studio 2019 version 16.11 (Preview 1) and through the dotnet watch command-line tooling in .NET 6 (Preview 4).

Now there’s Github issues being raised getting hammered with commends (, and even a PR that attempts to revert the changes ( under the guise of “Well if .NET is open source, then you have to accept this change”.

I usually avoid any sort of pitchfork display, so let’s tone down the verbiage a bit and actually just break down what’s happened :

  • In May, it was announced that dotnet watch and Visual Studio 2019 would have Hot Reload and was available now (And presumably Visual Studio 2022 would soon follow)
  • In October, it was announced that Visual Studio 2022 would be the only developer tool to receive Hot Reload, and a PR was created to remove hot reload from dotnet watch.
  • Follow up posts mention that Hot Reload itself maybe wasn’t production ready inside dotnet watch, or that Microsoft wanted to focus their efforts on hot reload being the best it could be in Visual Studio 2022, but developers feel like it’s simply a way to push people towards Visual Studio.
  • Given that Visual Studio is Windows Only, it implies that other operating systems will not receive hot reload in the near future, if at all. Especially if you do not use Visual Studio for Mac.
  • dotnet watch itself is *not* removed (I saw some people confused about this). The typical “dotnet watch build” dev flow is still applicable, it will just recompile your code instead of using hot reload.

So what’s going to happen? Microsoft will revert the decision. Almost certainly. At the very least you will see the feature being put behind an “experimental” flag on dotnet watch. A few years ago there was a similar issue on whether ASP.NET Core 2.0 should support .NET Framework as a runtime, Microsoft said no (Which I agreed with by the way!), community said yes, Microsoft said yes.

UPDATE : And a day later, Hot Reload is back in the CLI for .NET 6.

Want to learn more about Hot Reload? Check out the quick intro here :

Join over 3,000 subscribers who are receiving our weekly post digest, a roundup of this weeks blog posts.
We hate spam. Your email address will not be sold or shared with anyone else.

In the coming months I’ll be covering the new features of .NET 6, including things like MAUI (Cross platform GUI in .NET), PriorityQueue, and so much more. So I thought it would be worth talking a little bit on how to actually get set up to use .NET 6 if you are looking to touch this new tech early on.

In previous versions of .NET/.NET Core, the process to accessing preview versions was somewhat convoluted and involved installing a second “preview” version of Visual Studio to get up and running, but all that’s out the window now and things are easier than ever!

Setting Up .NET 6 SDK

To start, head over to the .NET 6 download page and download the latest SDK (not runtime!) for your operating system :

After installing, from a command prompt, you should be able to run “dotnet –info” and see something similar to the below :

.NET SDK (reflecting any global.json):
 Version:   6.0.100-preview.2.21155.3
 Commit:    1a9103db2d

It is important to note that this is essentially telling you that the default version of the .NET SDK is .NET 6 (Although, sometimes in Visual Studio, it will ignore preview versions as we will shortly see). This is important to note because any projects that don’t utilize a global.json will now be using .NET 6 (and a preview version at that). We have a short guide on how global.json can determine which SDK is used right here.

Setting Up Visual Studio For .NET 6

Now for the most part, developers of .NET will use Visual Studio. And the number one issue I find when people say “the latest version of .NET does not work in Visual Studio”, is because they haven’t downloaded the latest updates. I don’t care if a guide says “You only need version X.Y.Z” and you already have that. Obviously you need Visual Studio 2019, but no matter what anyone tells you about required versions, just be on the latest version.

You can check this by going to Help, then Check For Updates inside Visual Studio. The very latest version at the time of writing is 16.9.1, but again, download whatever version is available to you until it tells you you are up to date.

After installing the latest update, there is still one more feature flag to check. Go Tools -> Options, then select Preview Features as per the screenshot below. Make sure to tick the “Use previews of the .NET Core SDK”. Without this, Visual Studio will use the latest version of the .NET SDK installed, that is *not* a preview version. Obviously once .NET 6 is out of preview, you won’t need to do this, but if you are trying to play with the latest and greatest you will need this feature ticked.

After setting this, make sure to restart Visual Studio manually as it does not automatically do it for you. And you don’t want to be on the receiving end of your tech lead asking if you have “turned it off and on again” do you!

Migrating A Project To .NET 6

For the most part, Visual Studio will likely not create projects in .NET 6 by default when creating simple applications like console applications. This seems to vary but.. It certainly doesn’t for me. But that’s fine, all we have to do is edit our csproj file and change our target framework to net6.0 like so :


If you build and you get the following :

The current .NET SDK does not support targeting .NET 6.0.  Either target .NET 5.0 or lower, or use a version of the .NET SDK that supports .NET 6.0

The first thing to check is

  1. Do you have the correct .NET 6 SDK installed. If not, install it.
  2. Is .NET 6 still in preview? Then make sure you have the latest version of Visual Studio *and* have the “Use previews of the .NET Core SDK” option ticked as per above.

And that’s it! You’re now all set up to use the juicy goodness of .NET 6, and all those early access features in preview versions you’ve been waiting for!

Join over 3,000 subscribers who are receiving our weekly post digest, a roundup of this weeks blog posts.
We hate spam. Your email address will not be sold or shared with anyone else.

It feels like just last month .NET 6 Preview 1 was released…. In fact it was! Such is the cadence of releases with .NET now, they are getting pumped out at blazing speed. It means that each release only has marginal improvements each time, but it also means that you can grab the preview versions and actually start playing with features (and providing feedback) at a pretty crazy pace.

You can grab .NET 6 Preview 2 here :

Now as for what’s new, in short :

  • A key focus of .NET 6 is improving the developer experience by way of speeding up the feedback process of the tools you use every day. In Preview 2, that means showing off vastly improved build times across a range of projects (MVC and Blazor), in some cases cutting the build time by over half! If you are someone like me that runs a project using “dotnet watch”, then it’s great to see improvements in this area.
  • Further improvements to .NET Multi-platform App UI (Or MAUI for short), which means single project developer experiences not only across mobile platforms like Android and IOS, but even Mac OS too!
  • System.Text.Json now has a feature to “IgnoreCycles” which acts similar to the Newtonsoft.Json.ReferenceLoopHandling. This may sound like a small feature, but it’s actually been highly requested for a very long time now! For more information on what this fixes, we have a great article on it here :
  • Implementation of “PriorityQueue”. This is massive and a much needed enhancement! It allows developers to create a queue, but give each item in that queue a priority. On Dequeue, items with the highest priority are popped first. This will replace a tonne of custom coded “Queues” that are really un-performant lists in the background!

The full release notes as always is here :

Overall, those same minor improvements we’ve come to expect each release. But for me, the addition of the PriorityQueue is really great to see. Expect a blog post coming your way soon on the topic!

Join over 3,000 subscribers who are receiving our weekly post digest, a roundup of this weeks blog posts.
We hate spam. Your email address will not be sold or shared with anyone else.

It feels like not long ago we were talking about all the goodies in .NET 5, and here we are already jumping into .NET 6. It actually made me go back and look at the .NET Framework versions on Wikipedia here. Admittedly back then, minor versions of the framework sometimes contained huge changes. For example async/await was added in version 4.5, which these days would suggest a “minor” update, but obviously was pretty huge. But even still, version 1.0 to version 4.8 was 17 years in the making.

The first version of .NET Core was released in 2016, and here we are in 2021, just 5 years later, and we are already up to seeing preview versions of .NET Core 6. It really speaks to not only Microsoft’s commit to move fast, but I think just the overall cadence of modern software development. Gone are the days of developers sitting in cubicles and sitting on work for three years until a a major release.

You can grab .NET 6 Preview 1 here :

As for what’s new. Well generally the first preview release of a new .NET Version is typically setting the stage for what’s to come and doesn’t necessarily contain a lot of “toys” to play with. With that being said, some of the features that did make it in were :

  • The first iteration of moving Xamarin into .NET to unify the platforms. e.g. Being able to build Android/IOS applications in .NET.
  • A first crack at using Blazor for desktop applications (From early reading, this seems very close to how you might use Electron, e.g. It’s still a web control view on desktop).
  • There seems to be talk about better hot reload functionality. I can’t find that much information on this. The .NET CLI already has “dotnet watch“, but this is more of a complete build rather than a nice iterative hot reload.
  • Improvement to Single File Apps so that they actually execute from that single file rather than extracting into temp directories. This was already the case for single file applications for Linux in .NET 5, but in .NET 6, this functionality has been extended for Windows and Mac.
  • There is no appsettings.json auto complete for commonly used configuration such as logging, host filtering, kestrel setup etc.
  • WPF is now supported on ARM64.

The full release as always is here :

Overall, probably not a heck of a lot if you are a web developer. One of the major themes of .NET 6 (And even .NET 5), is unifying the various platforms and frameworks that sit under the .NET banner. In .NET 5, it was mostly desktop development, and in .NET 6, it’s a lot of mobile development with Xamarin. It doesn’t mean there won’t be something in future preview versions of course, but for now, get excited about mobile dev!

Join over 3,000 subscribers who are receiving our weekly post digest, a roundup of this weeks blog posts.
We hate spam. Your email address will not be sold or shared with anyone else.

With the announcement of .NET 5 last year, and subsequent announcements leading up to MSBuild 2020, a big question has been what’s going to happen to “.NET Standard”. That sort of framework that’s not an actual framework just an interface that various platforms/frameworks are required to implement, but not really, and then you have to get David Fowler to do a Github Gist that gets shared a million times to actually explain to people what the hell this thing is.

Anyway. .NET Standard is no more (Or will be eventually). As confusing as it may be at first to get rid of something that was only created 3 odd years ago… It does kinda make sense to get rid of it at this juncture.

Rewinding The “Why” We Even Had .NET Standard

Let’s take a step back and look at how and why .NET Standard came to be.

When .NET Core was first released, there was a conundrum. We have all these libraries that are already written for .NET Framework, do we really want to re-write them all for .NET Core? Given that the majority of early .NET Core was actually a port of .NET Framework to work cross platform, many of the classes and method signatures were identical (Infact I would go as far as to say most of them were).

Let’s use an example. Let’s say that I want to open a File inside my library using the standard File.ReadAllLines(string path) call. Now it just so happens if you write this code in .NET Framework, .NET Core or even Mono, it takes the same parameters (a string path variable), and returns the same thing, (a string array). Now *how* these calls read a file is up to the individual platform (For example .NET Core and Mono may have some special code to handle Mac path files), but the result should always be the same, a string array of lines from the file.

So if I had a library that does nothing but open a file to read lines and return it. Should I really need to release that library multiple times for different frameworks? Well, that’s where .NET Standard comes in. The simplest way to think about it is it defines a list of classes and methods that every platform agrees to implement. So if File.ReadAllLines() is part of the standard, then I can be assured that my library can be released once as a .NET Standard library, and it will work on multiple platforms.

If you’re looking for a longer explanation about .NET Standard, then there’s an article I wrote over 3 years ago that is still relevant today :

TL;DR; .NET Standard provided a way for different .NET Platforms to share a set of common method signatures that afforded library creators to write code once and be able to run on multiple platforms. 

.NET Standard Is No Longer Needed

So we come to the present day where announcements are coming out that .NET Standard is no longer relevant (sort of). And there’s two main reasons for that….

.NET Core Functionality Surpassed .NET Framework – Meaning New .NET Standard Versions Were Hard To Come By

Initially, .NET Core was a subset of .NET Framework functionality. So the .NET Standard was a way almost of saying, if you wrote a library for .NET Framework, here’s how you know it will work out of the box for .NET Core. Yes, .NET Standard was also used as a way to see functionality across other platforms like Mono, Xamarin, Silverlight, and even Windows Phone. But I feel like the majority of use cases were for .NET Framework => .NET Core comparisons.

As .NET Core built up it’s functionality, it was still essentially trying to reach feature parity with .NET Framework. So as a new version of .NET Core got released each year, a new version of .NET Standard also got released with it that was, again, almost exclusively to look at the common method signatures across .NET Framework <=> .NET Core. So eventually .NET Core surpasses .NET Framework, or at the very least says “We aren’t porting anything extra over”. This point is essentially .NET Standard 2.0.

But obviously work on .NET Core doesn’t stop, and new features are added to .NET Core that don’t exist in .NET Framework. But .NET Framework updates at first are few and far between,  until it’s announced that essentially it’s maintenance mode only (Or some variation there-of). So with the new features being added to .NET Core, do they make sense to be added to a new version of standard given that .NET Framework will never actually implement that standard? Kind of.. .Or atleast they tried. .NET Standard 2.1 was the latest release of the standard and (supposedly, although some would disagree), is implemented by both Mono and Xamarin, but not .NET Framework.

So now we have a standard that was devised to describe the parity between two big platforms, that one platform is no longer going to be participating in. I mean I guess we can keep implementing new standards but if there is only one big player actually adhering to that standard (And infact, probably defining it), then it’s kinda moot.

The Merger Of .NET Platforms Makes A Standard Double Moot

But then of course we rolled around 6 months after the release of .NET Standard 2.1,  and find the news that .NET Framework and .NET Core are being rolled into this single .NET platform called .NET 5. Now we are doubly not needing a standard because the two platforms we were trying to define the parity are actually just going to become one and the same.

Now take that, and add in the fact that .NET 6 is going to include the rolling in of the Xamarin platform. Now all those charts you saw of .NET Standard where you tried to trace your finger along the columns to check which version you should support are moot because there’s only one row now, that of .NET 6.

In the future there is only one .NET platform. There is no Xamarin, no .NET Core, no Mono, no .NET Framework. Just .NET.

So I Should Stop Using .NET Standard?

This was something that got asked of me recently. If it’s all becoming one platform, do we just start writing libraries for .NET 5 going forward then? The answer is no. .NET Standard will still exist as a way to write libraries that run in .NET Framework or older versions of .NET Core. Even today, when picking a .NET Standard version for a library, you try and pick the lowest number you can feasibly go to ensure you support as many platforms as you can. That won’t change going forward – .NET 5 still implements .NET Standard 1.0 for example, so any library that is targeting an older standard still runs on the latest version of the .NET platform.

What will change for the better are those hideously complex charts and nuget dependency descriptions on what platforms can run a particular library/package. In a few years from now it won’t be “Oh this library is for .NET Standard 2.1, Is that for .NET Core 2.1? No, it’s for .NET Core 3+… Who could have known”. Instead it will be, oh this library is for .NET 5, then it will work in .NET 7 no problems.

Join over 3,000 subscribers who are receiving our weekly post digest, a roundup of this weeks blog posts.
We hate spam. Your email address will not be sold or shared with anyone else.

So by now you’ve probably heard a little about various .NET 5 announcements and you’re ready to give it a try! I thought first I would give some of the cliffnotes from the .NET 5 announcement, and then jump into how to actually have a play with the preview version of .NET 5 (Correct as of writing this post on 2020-05-22).

Cliff Notes

  • .NET Standard is no more! Because .NET Framework and .NET Core are being merged, there is less of a need for .NET Standard. .NET Standard also covers things like Xamarin but that’s being rolled into .NET 6 (More on that a little later), so again, no need for it.
  • .NET Core coincides with C#9 and F#5 releases (As it typically does), but Powershell will now also be released on the same cadence.
  • They have added a visual designer for building WinForm applications since you could theoretically build WinForm applications in .NET Core 3.X but not design them with quite as much functionality as you typically would.
  • .NET 5 now runs on Windows ARM64.
  • While the concept of Single File Publish already exists in .NET Core 3.X, it looks like there has been improvements where it’s actually a true exe instead of a self extracting ZIP. Mostly for reasons around being on read-only media (e.g. A locked down user may not be able to extract that single exe to their temp folder etc).
  • More features have been added to System.Text.Json for feature parity with Newtonsoft.Json.
  • As mentioned earlier, Xamarin will be integrated with .NET 6 so that there would be a single unifying framework. Also looks like Microsoft will be doing a big push around the .NET ecosystem as a way to build apps once (in Xamarin), and deploy to Windows, Mac, IOS, Android etc. Not sure how likely this actually is but it looks like it’s the end goal.

Setting Up The .NET 5 SDK

So as always, the first thing you need to do is head to the .NET SDK Download page here : Note that if you go to the actual regular download page of you are only given the option to download .NET Core 3.1 or .NET Framework 4.8 (But there is a tiny little banner above saying where you can download the preview).

Anyway, download the .NET 5 SDK installer for your OS.

After installing, you can run the dotnet info command from a command prompt :

dotnet --info

Make sure that you do have the SDK installed correctly. If you don’t see .NET 5 in the list, the most common reason I’ve found is people installing the X86 version on their X64 PC. So make sure you get the correct installer!

Now if you use VS Code, you are all set. For any existing project you have that you want to test out running in .NET 5 (For example a small console app), then all you need to do is open the .csproj file and change :


To :


As noted in the cliffnotes above, because there is really only one Framework with no standard going forward, they ditched the whole “netcoreapp” thing and just went with “net”. That means if you want to update any of your .NET Standard libraries, you actually need them to target “net5.0” as well. But hold fire because there is actually no reason to bump the version of a library unless you really need something in .NET 5 (Pretty unlikely!).

.NET 5 In Visual Studio

Now if you’ve updated your .NET Core 3.1 app to .NET 5 and try and build in Visual Studio, you may just get :

The reference assemblies for .NETFramework,Version=v5.0 were not found. 

Not great! But all we need to do is update to the latest version and away we go. It’s somewhat lucky that there isn’t a Visual Studio release this year (e.g. There is no Visual Studio 2020), otherwise we would have to download yet another version of VS. So to update, inside Visual Studio, simply go Help -> Check For Updates. The version you want to atleast be on is 16.6 which as of right now, is the latest non-preview version.

Now after installing this update for the first time, for the life of me I couldn’t work out why I could build an existing .NET 5 project, but when I went to create a new project, I didn’t have the option of creating it as .NET 5.

As it turns out, by default the non-preview version of Visual Studio can only see non-preview versions of the SDK. I guess so that you can keep the preview stuff all together. If you are like me and just want to start playing without having to install the Preview version of VS, then you need to go Tools -> Options inside Visual Studio. Then inside the options window under Environment there is an option for “Preview Features”.

Tick this. Restart Visual Studio. And you are away laughing!

Do note that some templates such as Console Applications don’t actually prompt you for the SDK version when creating a new project, they just use the latest SDK available. In this case, your “default” for Visual Studio suddenly becomes a preview .NET Core SDK. Perfectly fine if you’re ready to sit on the edge, but just something to note in case this is a work machine or similar.


Join over 3,000 subscribers who are receiving our weekly post digest, a roundup of this weeks blog posts.
We hate spam. Your email address will not be sold or shared with anyone else.