Before we get into the technology and architecture of Rider, we must look at where this IDE came from. As far back as 2004, JetBrains was looking at a stand-alone application for the Visual Studio add-in ReSharper. It was never released, but a fully functional prototype was around at that time.
Asynchronous programming has been around for several years on the .NET platform but has historically been very difficult to do well. Since the introduction of async/await in C# 5 asynchronous programming has become mainstream. Modern frameworks (like ASP.NET Core) are fully asynchronous and it’s very hard to avoid the async keyword when writing web services. As a result, there’s been lots of confusion on the best practices for async and how to use it properly. This section will try to lay out some guidance with examples of bad and good patterns of how to write asynchronous code.
I’m here to tell a scary story; one of inefficient code and unhandled exceptions. A story about a .NET developer who used async/await, but didn’t fully understand the framework. Their code started experiencing strange bugs. Their app size was strangely large. GASP! Don’t let this happen to you.
In this campfire session, we are diving deep into the world of asynchronous programming to dissect how the .NET compiler handles asynchronous code and we’ll learn how small improvements to our asynchronous code can create huge performance gains.
PSA: This is your periodic reminder to run
dotnet nuget locals all –clear
To free up oodles of space in your NuGet package cache.
— Claire Novotny (@clairernovotny) October 23, 2018
This is really helpful as your local NuGet cache can get massive (in the gigabytes) with old packages you no longer ever restore.