A naive implementation of async lock

Behind the scenes the implementation uses SemaphoreSlim to do all the heavy lifting which already has a support for async/await.

You would normally use AsyncLock within a “using” statement. To keep the implementation as simple as possible I do not use any cancellation tokens for any of the operations.


private readonly AsyncLock _lock = new AsyncLock();
public async Task DoSomethingAsync()
  using (await _lock.EnterAsync())
    await Task.Delay(TimeSpan.FromSeconds(1));


Pinned: List of CQRS / Event Sourcing Resources

CQRS Pattern

CQRS stands for Command Query Responsibility Segregation. As the name suggests, we split the application in two parts: Command-Side and Query-Side. Now one will ask what this command and query means? Okay, so –

  • Commands are the ones that change the state of the object or entity, also called modifiers or mutators.
  • Queries are those that returns the state of the entity, and do not change anything. The another term for that will be accessors.

Why is it required?

In traditional data management systems, both commands and queries are executed against the same set of entities, having a single reprsentation or view. The CRUD operations are applied to a single datastore, the same entity or object is accessed to handle both read and write operations.

Issues with having single view for both read and write side –

  • Introduces the risks of data contention.
  • Managing permissions and security become complex as same objects are exposed to both read and write operations.

How CQRS solves this problem?

The CQRS pattern holds the idea that the method should either change the state of the entity, or returns the result, but not both. Segregating models for read and write side reduces the complexity that comes with having single view for both of them.

Benefits of CQRS –

  • Separate command and query models, results in simplified design and implementation of the system and overall reduction of complexity.
  • One can easily optimise the read side of the system separately from the write side, allows scaling each differently as per the load on the side. For example – Read datastores often encounters greater load, and hence can be scaled without affecting the write datastores.
  • You can provide multiple views of your data for querying purpose depending on the use cases.

How CQRS works?

CQRS is mainly used in conjuction with Event Sourcing. The write side model of the CQRS-based system handles the events persistence, acting as a source of information for the read side. The read model of the system provides materialized views of the data, typically as highly denormalized views.

Another Representation
cqrs event sourcing architecture

Example Implementation in C#

References & additional resources:

JetBrains Rider vs Visual Studio 2019

After using Rider for a day I just can’t go back to using Visual Studio 2019 + ReSharper combo. No matter how much you tweak it, it is still going to be very slow, especially for larger solutions.

I’m not someone who’s using a 5 year old notebook, my whole PC is build around being able to develop faster (almost), hence all my primary SSDs are the fastest M.2 drives around: C:\ 1TB, D:\ 2TB – SEAGATE FIRECUDA 520 GEN 4 PCIe NVMe (up to 5000MB/R, 4400MB/W) – I never saw anything faster than that on the market yet.

My PC Specs

In addition I have 128GB of RAM (DDR4 3200MHz) and AMD Ryzen Threadripper 3970X 32 Core CPU (3.7GHz – 4.5GHz, 147MB CACHE) which isn’t the fastest CPU around and I could have gone for the 64 core variant but that would be way over the top, since my overall CPU usage never goes up above 3%! while using VS 2019

CPU usage jump to 25% when starting Visual Studio and peaked at 87% while doing a rebuild on a large project PS: this is the first time I saw my CPU utilisation so high
Can’t resist any opportunity to show off my PC 🙂

The reason I deviated from conformity is because I had to modify .NET Framework version in several projects. Doing it in VS 2019 is extremely painful, in Rider you click and edit. It’s not slow, you don’t have to wait at all.

Where Rider is at its best

Here are some of the Rider features which I liked the most:

  • Rider = IntelliJ IDEA + ReSharper Rider comes with all the goodies of ReShaper without the performance tax. For the developers who cannot live without ReSharper, this can be huge.
Rider = IntelliJ IDEA + ReSharper
  • Faster build time: Rider can improve the build time drastically as compared to Visual Studio by applying heuristics to only build the projects that need to be updated. It can be a real performance booster for large solutions.  This post explains the incremental build feature in details.

Note: This feature was already available with ReSharper Build. So, if you are using ReSharper build instead of Visual Studio build management, then you might be already familiar with this. 

  • Seamless external source debugging: One of the features I liked about Rider was debugging external libraries/ nuget packages seamlessly like they are part of your code. And when you do not need to debug external source, you can turn off the feature.
Enable external source debug option
  • First-class support for Typescript/ Javascript debugging: I always felt Typescript/Javascript received a stepchild treatment in Visual Studio. With Rider, Typescript has first-class debugging support. You can debug within the IDE without switching to browser dev-tools.
  • Better Unit test experience: I have been a fan of ReSharper Unit test explorer window. And Rider only takes this forward. You can create multiple test window sessions and run only a subset of tests.
  • Great Git plugin: It would be an understatement to say that Rider’s Git plugin is better than Visual Studio. It offers the code analysis even during the merge, which can be huge since you can fix compile-time error or remove unused references at the time of merge.
  • Handling of large solutions: It is reasonable to expect that loading a large solution will take time. With Visual Studio, I encountered UI getting hanged several times during the project startup. Rider, on the other hand, handles it more gracefully. Like ReSharper, there is also an option to disable solution wide code analysis which can improve the load time.
  • Project Properties:  The project properties dialog in Rider supports the latest features of the new SDK project such as multi-target, setting language version, Nuget properties etc.
Project properties options in Rider
  • Event Log, Terminal window, create gist etc.: Rider comes up with an Event log window which the logs every event that happens with in the IDE. It also has a built-in Terminal and some excellent little features such create GitHub Gists from within the IDE. One other thing that impressed me was the ability to create custom “Run/Debug” templates. It offers much more than running a single project or “Multiple startup projects” option in Visual Studio.

There are some issues around NuGet handling but at the same time there are so many issues in VS 2019.

All of this was enough to buy a license

Automating creating NuGet packages with MSBuild

Code, the Universe and everything...

NuGet is a great way of shipping projects. You work on a project, you publish a package and it is immediately available to, literally, millions of developers. Creating a package consists of a few steps like authoring a .nuspec file, creating a folder structure, copying the right files to the right folders/subfolders and calling the nuget pack command. While the steps are not complicated they are error prone. I learnt this lesson when I shipped the first alpha versions of some of my NuGet packages. What happened was that I would create a package and then I would start feeling some doubts – did I really build the project before copying the files? did I copy the Release and not the Debug version? did I sign the file? And then people started using my packages and started asking (among other things) for a version that would work on other versions…

View original post 2,067 more words

Retrieving state in a FirstChanceException in .NET — Network Programming in .NET

If you’re using a application-wide FirstChanceException handler, this is great for covering lots of bases at once, it helps make sure that you can catch (and record) an exception even if it happens with a bit of code you didn’t expect. However, the scope of the handler is what it is, so accessing state, and […]

Retrieving state in a FirstChanceException in .NET — Network Programming in .NET

Free e-book: Blazor for ASP.NET Web Forms Developers — ASP.NET Blog

We are thrilled to announce the release of our new e-book: Blazor for ASP.NET Web Forms developers. This book caters specifically to ASP.NET Web Forms developers looking for guidelines. As well as strategies for migrating their existing apps to a modern, open-source, and cross-platform web framework. Blazor E-book for ASP.NET Web Forms Blazor is a…

Free e-book: Blazor for ASP.NET Web Forms Developers — ASP.NET Blog

The Most Easy to Use ViewModeBase

This is something I wrote for an application I’m developing. This is an implementation of INotifyPropertyChanged that requires no backing fields, just call Set(value) or Get(). Internally it uses a dictionary to store the state and even reuses ChangedEventArgs

The source code can be found at:

Here is the extract from the ViewModel class that does all the heavy lifting:

Continue reading “The Most Easy to Use ViewModeBase”

Does the usage of Thread.Sleep(…) warrant making the method Async in an API

Say you are developing an API where you have to use Thread.Sleep(…) since you are working with some device via a COM and you need to wait for the predefined amount of time before you can read from the device and there is no way around it. For example:

Rule in designing APIs in my head, is that you shouldn’t make something Async unless the underlying API(s) you are working with is also Async or uses BeginX EndX, continuations, i.e. something that is already asynchronous. By prematurely making something Async you are making an implementation decision for the consumer of the code. The code provided above doesn’t expose any such API.

Continue reading “Does the usage of Thread.Sleep(…) warrant making the method Async in an API”

C# Regrets: Top Worst C# Features

Stumbled upon this article written by no other than Eric Lippert listing the top 10 design faults of C# language. Here is the summary,  the source to the full article is at the bottom. 

#10: The empty statement does nothing for me

Reflects on the fact that lone “;” is a legal statement

#9: Too much equality

There are too many ways check for equality: ==, Equals, ReferenceEquals, CompareTo(…).

From personal experience double.NaN == double.NaN is false but double.NaN.Equals(double.NaN) is true

#8: That operator is shifty

Weirdness around << and >> operators

#7: I’m a proud member of lambda lambda lambda

The way C# 2.0 implements anonymous delegates

#6: Bit twiddling entails parentheses

Flags Enums

#5: Type first, ask questions later

C# borrows the “type first” pattern from C and many of its other successor languages – something I got used to and the “correct” way now seems illogical to me

#4: Flag me down

The fact that you can create invalid enum values and have to manually check for this in the code

#3: I rate plus-plus a minus-minus

++i, i++, i +=1 etc. how much confusion and the pain it caused.

#2 I want to destruct finalizers

Agree with the author that finilisers in C# are symptoms of a bug. Seen it way too many times myself.

#1 You can’t put a tiger in the goldfish tank, but you can try

“array covariance” and how this could lead to run-time exceptions.


Blog at

Up ↑