Asynchronous programming was incorporated into .NET a long time ago. To be more exact, asynchronous programming was introduced with 4.5 version of .NET. That happened on August 15th, 2012. Yes, six years ago. Yes, more than half a decade ago. Apart from sending me into a spiral of existential thoughts, this information made me think about the current understanding of asynchronous code in general.

You see, back then Windows Phone was still a thing, and making applications for these platforms had certain limitations. The main one was that Windows Phone, unlike desktop applications, introduced a hard limit in which no method could block for more than 50ms. This, in turn, meant that there was no more blocking of the UI for the developers, which led to the necessity for some sort of asynchronicity in the code. .NET 4.5 represents the response to this necessity.

So, why am I writing about something that happened more than half a decade ago? Well, I noticed that even though this is an old topic, there are still a lot of engineers that struggle with the concept. To quote Mike James from iProgrammer:

Often the programmer is fully aware that what they are doing is object oriented but only vaguely aware that they are writing asynchronous code.

That is why I tried to sum up the most important parts of this style of programming in a few blogs posts. Also, we will try to identify the situations in which we should use this programming style, as well as the situations when we should avoid it. So, let’s dive right into it:

• Asynchronous Programming in .NET – Motivation and Unit Testing
• Asynchronous Programming in .NET – Common Mistakes and Best Practices
• Asynchronous Programming in .NET – Task-based Asynchronous Pattern (TAP)
• Asynchronous Programming in .NET – Benefits and Tradeoffs of Using ValueTask

Thank you for reading!

Read more posts from the author at Rubik’s Code.