ConfigureAwait(false) not needed in Console/Win service apps, right?

Question

I have been using async/await for a while, but delved deeper recently, and read a lot of best practice tips saying to by default always use ConfigureAwait(false) to prevent deadlocks and improve performance.

I just want to make sure I am not missing something when I presume this only applies when the is an actual current SynchronizationContext or TaskScheduler in play, correct?

If I have a Windows service app that is responding to messages/commands/etc. asynchronously, it always just uses the default scheduler = probably the same threadpool thread that the awaitable completed on will execute the continuation, thus no deadlock and no performance difference can be had from using ConfigureAwait(false), correct?

It's not like I can't put it there, but I hate noisey code so much...

Answer 1

In general, this is true. When working in a Console or Service scenario, there is no SynchronizationContext installed (by default) so the continueOnCapturedContext option in ConfigureAwait will have no effect, which means you can safely remove it without changing the runtime behavior.

However, there can be exceptions, so I would often suggest writing your code including ConfigureAwait(false) when appropriate anyways.

The main advantages of including this even in a console or service application are:

1. The code becomes reusable in other applications later. If you choose to reuse this code, you won't have to track down bugs that arise from not including this.
2. If you happen to install (or use a library that installs) a SynchronizationContext while running, the behavior of your methods won't change.