title: A case when ConfigureAwait(false) causes an error instead of deadlock
body: <p>Suppose I have written a library which relies on <code>async</code> methods:</p>
  
  <pre><code>namespace MyLibrary1
  {
      public class ClassFromMyLibrary1
      {
          public async Task&lt;string&gt; MethodFromMyLibrary1(string key, Func&lt;string, Task&lt;string&gt;&gt; actionToProcessNewValue)
          {
              var remoteValue = await GetValueByKey(key).ConfigureAwait(false);
  
              //do some transformations of the value
              var newValue = string.Format("Remote-{0}", remoteValue);
  
              var processedValue = await actionToProcessNewValue(newValue).ConfigureAwait(false);
  
              return string.Format("Processed-{0}", processedValue);
          }
  
          private async Task&lt;string&gt; GetValueByKey(string key)
          {
              //simulate time-consuming operation
              await Task.Delay(500).ConfigureAwait(false);
  
              return string.Format("ValueFromRemoteLocationBy{0}", key);
          }
      }
  }
  </code></pre>
  
  <p>I followed the recommendations of using <code>ConfigureAwait(false)</code> (like in <a href="https://msdn.microsoft.com/en-us/magazine/jj991977.aspx" rel="nofollow">this</a> post) everywhere in my library. Then I use it in <strong>synchronous</strong> way from my test app and get a failure:</p>
  
  <pre><code>namespace WpfApplication1
  {
      /// &lt;summary&gt;
      /// Interaction logic for MainWindow.xaml
      /// &lt;/summary&gt;
      public partial class MainWindow : Window
      {
          public MainWindow()
          {
              InitializeComponent();
          }
  
          private void Button1_OnClick(object sender, RoutedEventArgs e)
          {
              try
              {
                  var c = new ClassFromMyLibrary1();
  
                  var v1 = c.MethodFromMyLibrary1("test1", ActionToProcessNewValue).Result;
  
                  Label2.Content = v1;
              }
              catch (Exception ex)
              {
                  System.Diagnostics.Trace.TraceError("{0}", ex);
                  throw;
              }
          }
  
          private Task&lt;string&gt; ActionToProcessNewValue(string s)
          {
              Label1.Content = s;
              return Task.FromResult(string.Format("test2{0}", s));
          }
      }
  }
  </code></pre>
  
  <p>The failure is:</p>
  
  <blockquote>
    <p>WpfApplication1.vshost.exe Error: 0 :
    System.InvalidOperationException: The calling thread cannot access
    this object because a different thread owns it.    at
    System.Windows.Threading.Dispatcher.VerifyAccess()    at
    System.Windows.DependencyObject.SetValue(DependencyProperty dp, Object
    value)    at System.Windows.Controls.ContentControl.set_Content(Object
    value)    at WpfApplication1.MainWindow.ActionToProcessNewValue(String
    s) in
    C:\dev\tests\4\WpfApplication1\WpfApplication1\MainWindow.xaml.cs:line
    56    at
    MyLibrary1.ClassFromMyLibrary1.d__0.MoveNext()
    in
    C:\dev\tests\4\WpfApplication1\WpfApplication1\MainWindow.xaml.cs:line
    77
    --- End of stack trace from previous location where exception was thrown ---    at
    System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task
    task)    at
    System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task
    task)    at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult() 
    at WpfApplication1.MainWindow.d__1.MoveNext() in
    C:\dev\tests\4\WpfApplication1\WpfApplication1\MainWindow.xaml.cs:line
    39 Exception thrown: 'System.InvalidOperationException' in
    WpfApplication1.exe</p>
  </blockquote>
  
  <p>Obviously the error happens because the awaiters in my library discard current WPF context.</p>
  
  <p>From the other hand, after removing the <code>ConfigureAwait(false)</code> everywhere in the library I obviously get a deadlock instead.</p>
  
  <p><a href="https://dotnetfiddle.net/I4VBJs" rel="nofollow">There is more detailed example of code</a> which explains some constraints that I have to deal with.</p>
  
  <p>So how can I address this issue? What is the best approach here? Do I still need to follow the best practice regarding <code>ConfigureAwait</code>?</p>
  
  <p>PS, In real scenario I have many classes and methods therefore tons of such async calls in my library. It's nearly impossible to find out if some particular async call requires context or not (see comments to @Alisson response) to fix it. I don't care about performance though, at least at this point. I'm looking for some general approach to address this issue.</p>