Async library best practice: ConfigureAwait(false) vs. setting the synchronization context : <p>It's well-known that in a general-purpose library, <code>ConfigureAwait(false)</code> should be used on every await call to avoid continuing on the current SynchronizationContext.</p>

<p>As an alternative to peppering the entire codebase with <code>ConfigureAwait(false)</code>, one could simply set the SynchronizationContext to null once, at the public surface method, and restore it before returning to the user. In other words:</p>

<pre><code>public async Task SomeSurfaceMethod()
{
    var callerSyncCtx = SynchronizationContext.Current;
    SynchronizationContext.SetSynchronizationContext(null);
    try
    {
        // Do work
    }
    finally
    {
        SynchronizationContext.SetSynchronizationContext(callerSyncCtx);
    }
}
</code></pre>

<p>This could also be wrapped in a <code>using</code> for better readability.</p>

<p>Is there a disadvantage to this approach, does it not end up producing the same effect?</p>

<p>The major advantage is obviously readability - the removal of all <code>ConfigureAwait(false)</code> calls. It may also reduce the likelihood of forgetting a <code>ConfigureAwait(false)</code> somewhere (although analyzers mitigate this, and it could be argued that developers could just as well forget changing the SynchronizationContext).</p>

<p>A somewhat exotic advantage is not embedding the choice of capturing the SynchronizationContext or not in all methods. In other words, in one case I may want to run method X with a SynchronizationContext, while in another I may want to run the same method without one. When <code>ConfigureAwait(false)</code> is embedded everywhere that isn't possible. Granted, this is quite a rare requirement, but I bumped into it while working on Npgsql (triggering this question).</p>
