async await “explained” by examples

What does async and await really do?

Using the await keyword is basically just waiting for whatever function that comes after that keyword to create a thread, do work and return to the calling thread once it is done.
Everything that comes after is a “continuation”
The following 2 functions do pretty much the same thing

The above should also indicate something else, namely continuation.
In the first method everything after the “Task” calls would probably run before the tasks would finish.
In the latter, everything after the await call IS the continuation.
So doing something like the following;

Would result in the function taking around 6 seconds to do its “work”, since everything is a continuation of the former.
– this is probably not what you would want.
Instead you can do something like this;

Which would take around 2 seconds.


Using async and await there is something to note in regards to exceptions:
I found this in an MSDN article and I think it explains it pretty well.

Async void methods have different error-handling semantics. When an exception is thrown out of an async Task or async Task method, that exception is captured and placed on the Task object. With async void methods, there is no Task object, so any exceptions thrown out of an async void method will be raised directly on the SynchronizationContext that was active when the async void method started. Exceptions thrown from async void methods can’t be caught naturally.

The following code should explain:

So never ever use async void – it will take days to figure out what is actually going on.
If you have any questions please comment below and I will try to update the article with an answer 🙂

Easy, simple HttpRuntime.Cache

A simple to use caching function that both gets and/or sets the key depending on results.

This is a post for my future self. – Hi future self! (wave).
The following is an easy to use caching function.

The function gets or updates based on results.
The wrapper helps create different cacheExpirations based on needs.

Versioning WebApi and documenting version with Swagger

Versioning in WebApi

Note: This post draws alot of points from – but is more about implementation and documentation through swagger.
So please go read Troy’s post and then come back :).
There are a couple of ways of versioning a restful api
among them are:
1. Url versioning e.g. GET
2. Request-Header e.g. GET — Header: api-version: 1
There are pros and cons in both regards, Troy gets around them quite nicely.
Time to code!

Url Versioning

Easy – simply use either the RoutePrefix- or RouteAttribute

Read more about the Routing-Attribute here


Drawing from Troy’s post
We create a new attribute which uses a custom routing constraint

** Usage **

Effectively matching routes based on the “api-version” header.


When using swashbuckle (swagger implementation for .Net).
It knows about the default Route- and RoutePrefixAttribute, so Url Versioning is taken care of, out of the box.
But Header versioning is not.
Fortunately, it’s quite easy to implement an OperationFilter that adds the header as a parameter to the endpoints in question.
This implementation uses a list of versions and the endpoints relativepaths to know when to add the parameter and when not to.

How would you implement the OperationFilter?