Случай, когда ConfigureAwait(false) вместо взаимоблокировки вызывает ошибку

Обычно библиотека будет документировать, если обратный вызов гарантированно будет в том же потоке, который его вызвал, если он не задокументирован, самым безопасным вариантом будет предположить, что это не так. Ваш пример кода (и третья сторона, с которой вы работаете, насколько я могу судить из ваших комментариев) подпадают под категорию «Не гарантируется». В этой ситуации вам просто нужно проверить, нужно ли вам сделать Invoke внутри метода обратного вызова, и сделайте это, вы можете вызвать Dispatcher.CheckAccess(), и он вернет false, если вам нужно вызвать перед использованием элемента управления.

private async Task<string> ActionToProcessNewValue(string s)
{
    //I like to put the work in a delegate so you don't need to type 
    // the same code for both if checks
    Action work = () => Label1.Content = s;
    if(Label1.Dispatcher.CheckAccess())
    {
        work();
    }
    else
    {
        var operation = Label1.Dispatcher.InvokeAsync(work, DispatcherPriority.Send);

        //We likely don't need .ConfigureAwait(false) because we just proved
        // we are not on the UI thread in the if check.
        await operation.Task.ConfigureAwait(false);
    }

    return string.Format("test2{0}", s);
}

Вот альтернативная версия с синхронным обратным вызовом вместо асинхронного.

private string ActionToProcessNewValue(string s)
{
    Action work = () => Label1.Content = s;
    if(Label1.Dispatcher.CheckAccess())
    {
        work();
    }
    else
    {
        Label1.Dispatcher.Invoke(work, DispatcherPriority.Send);
    }

    return string.Format("test2{0}", s);
}

Вот еще одна версия, если вы хотите получить значение из Label1.Content вместо его назначения, для этого также не нужно использовать async/await внутри обратного вызова.

private Task<string> ActionToProcessNewValue(string s)
{
    Func<string> work = () => Label1.Content.ToString();
    if(Label1.Dispatcher.CheckAccess())
    {
        return Task.FromResult(work());
    }
    else
    {
        return Label1.Dispatcher.InvokeAsync(work, DispatcherPriority.Send).Task;
    }
}

ВАЖНОЕ ПРИМЕЧАНИЕ: все эти методы заставят вашу программу зайти в тупик, если вы не избавитесь от .Result в обработчике нажатия кнопки, Dispatcher.Invoke или Dispatcher.InvokeAsync в обратном вызове никогда не запустятся, пока они ожидание возврата .Result, а .Result никогда не вернется, пока он ожидает возврата обратного вызова. Вы должны изменить обработчик щелчка на async void и сделать await вместо .Result.

Фактически, вы получаете обратный вызов в своем ClassFromMyLibrary1 и не можете предположить, что он будет делать (например, обновлять метку). Вам не нужно ConfigureAwait(false) в вашей библиотеке классов, так как та же ссылка, которую вы предоставили, дает нам такое объяснение:

По мере роста асинхронных приложений с графическим интерфейсом вы можете обнаружить множество небольших частей асинхронных методов, использующих поток графического интерфейса в качестве своего контекста. Это может вызвать медлительность, так как скорость отклика страдает от «тысяч порезов бумаги».

Чтобы смягчить это, ждите результата ConfigureAwait всякий раз, когда это возможно.

Используя ConfigureAwait, вы обеспечиваете небольшой уровень параллелизма: некоторый асинхронный код может выполняться параллельно с потоком графического интерфейса вместо того, чтобы постоянно загружать его какой-то работой.

А теперь почитайте здесь:

Вы не должны использовать ConfigureAwait, если у вас есть код после ожидания в методе, которому нужен контекст. Для приложений с графическим интерфейсом это включает в себя любой код, который манипулирует элементами графического интерфейса, записывает свойства с привязкой к данным или зависит от конкретного типа графического интерфейса, такого как Dispatcher/CoreDispatcher.

Вы делаете ровно наоборот. Вы пытаетесь обновить графический интерфейс в двух точках: одна в вашем методе обратного вызова, а другая здесь:

var c = new ClassFromMyLibrary1();

var v1 = c.MethodFromMyLibrary1("test1", ActionToProcessNewValue).Result;

Label2.Content = v1; // updating GUI...

Вот почему удаление ConfigureAwait(false) решает вашу проблему. Кроме того, вы можете сделать обработчик нажатия кнопки асинхронным и дождаться вызова метода ClassFromMyLibrary1.

На мой взгляд, вам следует перепроектировать API вашей библиотеки, чтобы не смешивать API на основе обратного вызова с API на основе задач. По крайней мере, в вашем примере кода нет веских оснований для этого, и вы указали одну причину, по которой этого не делать - трудно контролировать контекст, в котором выполняется ваш обратный вызов.

Я бы изменил API вашей библиотеки так:

namespace MyLibrary1
{
    public class ClassFromMyLibrary1
    {
        public async Task<string> MethodFromMyLibrary1(string key)
        {
            var remoteValue = await GetValueByKey(key).ConfigureAwait(false);
            return remoteValue;
        }

        public string TransformProcessedValue(string processedValue)
        {
            return string.Format("Processed-{0}", processedValue);
        }

        private async Task<string> GetValueByKey(string key)
        {
            //simulate time-consuming operation
            await Task.Delay(500).ConfigureAwait(false);

            return string.Format("ValueFromRemoteLocationBy{0}", key);
        }
    }
}

И назовите это так:

   private async void Button1_OnClick(object sender, RoutedEventArgs e)
    {
        try
        {
            var c = new ClassFromMyLibrary1();

            var v1 = await c.MethodFromMyLibrary1("test1");
            var v2 = await ActionToProcessNewValue(v1);
            var v3 = c.TransformProcessedValue(v2);

            Label2.Content = v3;
        }
        catch (Exception ex)
        {
            System.Diagnostics.Trace.TraceError("{0}", ex);
            throw;
        }
    }

    private Task<string> ActionToProcessNewValue(string s)
    {
        Label1.Content = s;
        return Task.FromResult(string.Format("test2{0}", s));
    }