The art of simplicity

You maybe used Parallel.ForEach() before. It allows to iterate over a collection in a parallel way. It works similar to a Parallel.For loop. The loop partitions the source collection and schedules the work on multiple threads based  on the available processors in a system. Unfortunately the Parallel.ForEach() cannot be used for asynchronous work. Async vs parallel It is important to understand that "async" and "parallel" are two different concepts. Although they are both related to concurrent programming, they serve different purposes and are used in different contexts. Async is used to make non-blocking I/O operations and asynchronous code execution. It is primarily used for tasks that may take some time to complete, like reading from a file, making a network request, or performing database operations. Parallel however refers to parallel programming, which is about executing multiple tasks or operations simultaneously to improve performance and ...

Services in .NET Core can be registered using the built-in dependency injection functionality with different lifetimes: Transient Scoped Singleton Scoped services are created for a specific period of time linked to a scope. For example when using ASP.NET Core a scoped service lifetime is coupled to a client request. An important feature of scoped services is that they are disposed when the scope is closed. It is possible to create a scope yourself using the CreateScope method on the IServiceProvider : If you run the example above you’ll see that the Foo instance is correctly disposed after leaving the scope. So far, so good. But what about when your service implements the IAsyncDisposable interface instead? To support this scenario in a non-breaking way, a new CreateAsyncScope method is introduced on the IServiceProvider interface in .NET 6. Here is an updated example using this feature: Remark : ASP.NET Core was updated as well and implementations o...

Over the years there have been multiple ways to write asynchronous code in .NET with async/await being the latest attempt to make it less error-prone and more developer friendly. We started the asynchronous journey in .NET 1.0 with the Asynchronous Programming Model where you had to write a Begin and End method following a specific pattern: This was improved in .NET 2.0 with the introduction of the Event-Based Asynchronous pattern(focussing mainly on client applications) in combination with the SynchronizationContext simplifying the scheduling of work on the UI thread: In .NET 4.0 the System.Threading.Tasks.Task type was introduced, a data structure that represents the eventual completion of some asynchronous operation: And finally we arrived at async/await where we use the power of iterators to generate a state machine that handles all the continuations and callbacks for us. This allows us to write asynchronous code in a way that almost feel as synchronous simplifying...

Although IAsyncEnumerable is a part of the C# 8 release and C# 8.0 is supported on .NET Core 3.x and .NET Standard 2.1 , this doesn’t have to mean that you cannot use this feature in .NET Core 2.x or the full .NET Framework. We’ll start with the following (failing to compile) code in a .NET 4.7 project and try to make it work: A .NET Standard 2.0 project doesn’t know the IAsyncEnumerable interface. So the first thing we need to do is to install the compatibility NuGet package Microsoft.Bcl.AsyncInterfaces . Now the compiler finds the IAsyncEnumerable interface but Visual Studio still complains because we are targeting C# 7.3 and asynchronous streams is a C# 8 feature. We can fix this but this requires that the following things are installed on our computer: .NET Core SDK 3.0 or MSBuild Tools 2019 Visual Studio 2019 or VSCode If these requirements are met we can update our project file and tell the compiler to use C# 8 as the language version: Unload the ...

A colleague was having some trouble with his ASP.NET MVC 4 application. Whe he started his application, the process “hanged” and he had to kill the w3wp process to be able to restart. We were able to pinpoint the problem to a call to an async method inside an Action Filter: It seems that there is no support for async filters in ASP.NET MVC 4. The call to .Result in the action filter resulted in a blocking operation making the whole application pool unavailable. We solved it by switching to a non async version of the api. Remark: Note that ASP.NET Web API does have support for async action filters.

While investigating an Entity Framework issue, I stumbled over the following exception The source IQueryable doesn't implement IDbAsyncEnumerable<VLM.PlattelandsLoket.Domain.Views.Codes.CodeValueView>. Only sources that implement IDbAsyncEnumerable can be used for Entity Framework asynchronous operations. For more details see http://go.microsoft.com/fwlink/?LinkId=287068 . What’s causing this error? Entity Framework 6 introduced async support through a set of extension methods. These extension methods are defined on IQueryable and IEnumerable but actually expect an IDbAsyncEnumerable implementation behind the scenes  to work. When you try to use one of these extension methods on a LINQ query that isn’t an Entity Framework query, you end up with the error message above. I have to say I’m not a big fan of this approach, it sounds like a ‘leaky abstraction’ to me. What do you think? Code smell or not?