Como chamar o método assíncrono do método síncrono em c #?

Eu tenho um public async void Foo()método que eu quero chamar do método síncrono. Até agora, tudo o que vi na documentação do MSDN está chamando métodos assíncronos por métodos assíncronos, mas todo o meu programa não é construído com métodos assíncronos.

Isso é possível?

Aqui está um exemplo de chamada desses métodos de um método assíncrono: http://msdn.microsoft.com/en-us/library/hh300224(v=vs.110).aspx

Agora, estou tentando chamar esses métodos assíncronos a partir de métodos de sincronização.

A programação assíncrona "cresce" através da base de código. Foi comparado a um vírus zumbi . A melhor solução é permitir que ela cresça, mas às vezes isso não é possível.

Escrevi alguns tipos na minha biblioteca Nito.AsyncEx para lidar com uma base de código parcialmente assíncrona. Porém, não há solução que funcione em todas as situações.

Solução A

Se você possui um método assíncrono simples que não precisa ser sincronizado de volta ao seu contexto, pode usar Task.WaitAndUnwrapException:

var task = MyAsyncMethod();
var result = task.WaitAndUnwrapException();

Você não deseja usar Task.Waitou Task.Resultporque eles envolvem exceções AggregateException.

Esta solução é apropriada apenas se MyAsyncMethodnão for sincronizada de volta ao seu contexto. Em outras palavras, todo awaitem MyAsyncMethoddeve terminar com ConfigureAwait(false). Isso significa que não é possível atualizar nenhum elemento da interface do usuário nem acessar o contexto de solicitação do ASP.NET.

Solução B

Se MyAsyncMethodprecisar sincronizar de volta ao seu contexto, você poderá usar AsyncContext.RunTaskpara fornecer um contexto aninhado:

var result = AsyncContext.RunTask(MyAsyncMethod).Result;

* Atualização 14/04/2014: nas versões mais recentes da biblioteca, a API é a seguinte:

var result = AsyncContext.Run(MyAsyncMethod);

(Não há problema em usar Task.Resultneste exemplo, porque RunTaskpropagará Taskexceções).

O motivo pelo qual você pode precisar, em AsyncContext.RunTaskvez de, Task.WaitAndUnwrapExceptioné por causa de uma possibilidade bastante sutil de conflito que ocorre no WinForms / WPF / SL / ASP.NET:

1. Um método síncrono chama um método assíncrono, obtendo a Task.
2. O método síncrono faz uma espera de bloqueio no Task.
3. O asyncmétodo usa awaitsem ConfigureAwait.
4. O Tasknão pode ser concluído nessa situação porque ele é concluído apenas quando o asyncmétodo é concluído; o asyncmétodo não pode ser concluído porque está tentando agendar sua continuação para SynchronizationContext, e WinForms / WPF / SL / ASP.NET não permitirá que a continuação seja executada porque o método síncrono já está sendo executado nesse contexto.

Essa é uma das razões pelas quais é uma boa ideia usar o máximo possível ConfigureAwait(false)em todos os asyncmétodos.

Solução C

AsyncContext.RunTasknão funcionará em todos os cenários. Por exemplo, se o asyncmétodo aguardar algo que exija a conclusão de um evento da interface do usuário, você entrará em conflito mesmo com o contexto aninhado. Nesse caso, você pode iniciar o asyncmétodo no pool de threads:

var task = Task.Run(async () => await MyAsyncMethod());
var result = task.WaitAndUnwrapException();

No entanto, esta solução requer um MyAsyncMethodque funcione no contexto do conjunto de encadeamentos. Portanto, ele não pode atualizar elementos da interface do usuário nem acessar o contexto de solicitação do ASP.NET. E, nesse caso, você também pode adicionar ConfigureAwait(false)suas awaitdeclarações e usar a solução A.

Atualização, 01/05/2019: As "práticas menos recomendadas" atuais estão em um artigo do MSDN aqui .

Adicionando uma solução que finalmente resolveu meu problema, espero poupar o tempo de alguém.

Leia primeiro alguns artigos de Stephen Cleary :

• Assíncrono e Aguardar
• Não bloqueie no código assíncrono

Das "duas melhores práticas" em "Não bloqueie no código assíncrono", a primeira não funcionou para mim e a segunda não foi aplicável (basicamente, se eu posso usar await, eu faço!).

Então, aqui está minha solução alternativa: encerre a chamada dentro de um Task.Run<>(async () => await FunctionAsync());e esperamos que não haja mais impasse .

Aqui está o meu código:

public class LogReader
{
    ILogger _logger;

    public LogReader(ILogger logger)
    {
        _logger = logger;
    }

    public LogEntity GetLog()
    {
        Task<LogEntity> task = Task.Run<LogEntity>(async () => await GetLogAsync());
        return task.Result;
    }

    public async Task<LogEntity> GetLogAsync()
    {
        var result = await _logger.GetAsync();
        // more code here...
        return result as LogEntity;
    }
}

A Microsoft criou uma classe AsyncHelper (interna) para executar o Async como Sync. A fonte se parece com:

internal static class AsyncHelper
{
    private static readonly TaskFactory _myTaskFactory = new 
      TaskFactory(CancellationToken.None, 
                  TaskCreationOptions.None, 
                  TaskContinuationOptions.None, 
                  TaskScheduler.Default);

    public static TResult RunSync<TResult>(Func<Task<TResult>> func)
    {
        return AsyncHelper._myTaskFactory
          .StartNew<Task<TResult>>(func)
          .Unwrap<TResult>()
          .GetAwaiter()
          .GetResult();
    }

    public static void RunSync(Func<Task> func)
    {
        AsyncHelper._myTaskFactory
          .StartNew<Task>(func)
          .Unwrap()
          .GetAwaiter()
          .GetResult();
    }
}

As classes base Microsoft.AspNet.Identity possuem apenas métodos Async e, para chamá-las como Sincronização, existem classes com métodos de extensão que se parecem com (exemplo de uso):

public static TUser FindById<TUser, TKey>(this UserManager<TUser, TKey> manager, TKey userId) where TUser : class, IUser<TKey> where TKey : IEquatable<TKey>
{
    if (manager == null)
    {
        throw new ArgumentNullException("manager");
    }
    return AsyncHelper.RunSync<TUser>(() => manager.FindByIdAsync(userId));
}

public static bool IsInRole<TUser, TKey>(this UserManager<TUser, TKey> manager, TKey userId, string role) where TUser : class, IUser<TKey> where TKey : IEquatable<TKey>
{
    if (manager == null)
    {
        throw new ArgumentNullException("manager");
    }
    return AsyncHelper.RunSync<bool>(() => manager.IsInRoleAsync(userId, role));
}

Para aqueles preocupados com os termos de código de licenciamento, aqui está um link para código muito semelhante (apenas adiciona suporte à cultura no encadeamento) que possui comentários para indicar que ele é licenciado pelo MIT pela Microsoft. https://github.com/aspnet/AspNetIdentity/blob/master/src/Microsoft.AspNet.Identity.Core/AsyncHelper.cs

O async Main agora faz parte do C # 7.2 e pode ser ativado nas configurações avançadas de construção do projeto.

Para C # <7.2, a maneira correta é:

static void Main(string[] args)
{
   MainAsync().GetAwaiter().GetResult();
}


static async Task MainAsync()
{
   /*await stuff here*/
}

Você verá isso usado em muitas documentações da Microsoft, por exemplo: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-how-to-use- tópicos-assinaturas

public async Task<string> StartMyTask()
{
    await Foo()
    // code to execute once foo is done
}

static void Main()
{
     var myTask = StartMyTask(); // call your method which will return control once it hits await
     // now you can continue executing code here
     string result = myTask.Result; // wait for the task to complete to continue
     // use result

}

Você lê a palavra-chave 'aguardar' como "inicie esta tarefa de longa execução e retorne o controle ao método de chamada". Depois que a tarefa de execução longa é concluída, ela executa o código após ela. O código após a espera é semelhante ao que costumava ser métodos de retorno de chamada. A grande diferença é que o fluxo lógico não é interrompido, o que facilita muito a escrita e a leitura.

Não tenho 100% de certeza, mas acredito que a técnica descrita neste blog deve funcionar em várias circunstâncias:

Assim, você pode usar task.GetAwaiter().GetResult()se desejar invocar diretamente essa lógica de propagação.

No entanto, existe uma boa solução que funciona em (quase: veja comentários) todas as situações: uma bomba de mensagens ad-hoc (SynchronizationContext).

O encadeamento de chamada será bloqueado conforme o esperado, garantindo ainda que todas as continuações chamadas da função assíncrona não entrem em conflito, pois serão empacotadas para o SynchronizationContext (bomba de mensagens) ad-hoc em execução no encadeamento de chamada.

O código do auxiliar de bomba de mensagem ad-hoc:

using System;
using System.Collections.Concurrent;
using System.Collections.Generic;
using System.Threading;
using System.Threading.Tasks;

namespace Microsoft.Threading
{
    /// <summary>Provides a pump that supports running asynchronous methods on the current thread.</summary>
    public static class AsyncPump
    {
        /// <summary>Runs the specified asynchronous method.</summary>
        /// <param name="asyncMethod">The asynchronous method to execute.</param>
        public static void Run(Action asyncMethod)
        {
            if (asyncMethod == null) throw new ArgumentNullException("asyncMethod");

            var prevCtx = SynchronizationContext.Current;
            try
            {
                // Establish the new context
                var syncCtx = new SingleThreadSynchronizationContext(true);
                SynchronizationContext.SetSynchronizationContext(syncCtx);

                // Invoke the function
                syncCtx.OperationStarted();
                asyncMethod();
                syncCtx.OperationCompleted();

                // Pump continuations and propagate any exceptions
                syncCtx.RunOnCurrentThread();
            }
            finally { SynchronizationContext.SetSynchronizationContext(prevCtx); }
        }

        /// <summary>Runs the specified asynchronous method.</summary>
        /// <param name="asyncMethod">The asynchronous method to execute.</param>
        public static void Run(Func<Task> asyncMethod)
        {
            if (asyncMethod == null) throw new ArgumentNullException("asyncMethod");

            var prevCtx = SynchronizationContext.Current;
            try
            {
                // Establish the new context
                var syncCtx = new SingleThreadSynchronizationContext(false);
                SynchronizationContext.SetSynchronizationContext(syncCtx);

                // Invoke the function and alert the context to when it completes
                var t = asyncMethod();
                if (t == null) throw new InvalidOperationException("No task provided.");
                t.ContinueWith(delegate { syncCtx.Complete(); }, TaskScheduler.Default);

                // Pump continuations and propagate any exceptions
                syncCtx.RunOnCurrentThread();
                t.GetAwaiter().GetResult();
            }
            finally { SynchronizationContext.SetSynchronizationContext(prevCtx); }
        }

        /// <summary>Runs the specified asynchronous method.</summary>
        /// <param name="asyncMethod">The asynchronous method to execute.</param>
        public static T Run<T>(Func<Task<T>> asyncMethod)
        {
            if (asyncMethod == null) throw new ArgumentNullException("asyncMethod");

            var prevCtx = SynchronizationContext.Current;
            try
            {
                // Establish the new context
                var syncCtx = new SingleThreadSynchronizationContext(false);
                SynchronizationContext.SetSynchronizationContext(syncCtx);

                // Invoke the function and alert the context to when it completes
                var t = asyncMethod();
                if (t == null) throw new InvalidOperationException("No task provided.");
                t.ContinueWith(delegate { syncCtx.Complete(); }, TaskScheduler.Default);

                // Pump continuations and propagate any exceptions
                syncCtx.RunOnCurrentThread();
                return t.GetAwaiter().GetResult();
            }
            finally { SynchronizationContext.SetSynchronizationContext(prevCtx); }
        }

        /// <summary>Provides a SynchronizationContext that's single-threaded.</summary>
        private sealed class SingleThreadSynchronizationContext : SynchronizationContext
        {
            /// <summary>The queue of work items.</summary>
            private readonly BlockingCollection<KeyValuePair<SendOrPostCallback, object>> m_queue =
                new BlockingCollection<KeyValuePair<SendOrPostCallback, object>>();
            /// <summary>The processing thread.</summary>
            private readonly Thread m_thread = Thread.CurrentThread;
            /// <summary>The number of outstanding operations.</summary>
            private int m_operationCount = 0;
            /// <summary>Whether to track operations m_operationCount.</summary>
            private readonly bool m_trackOperations;

            /// <summary>Initializes the context.</summary>
            /// <param name="trackOperations">Whether to track operation count.</param>
            internal SingleThreadSynchronizationContext(bool trackOperations)
            {
                m_trackOperations = trackOperations;
            }

            /// <summary>Dispatches an asynchronous message to the synchronization context.</summary>
            /// <param name="d">The System.Threading.SendOrPostCallback delegate to call.</param>
            /// <param name="state">The object passed to the delegate.</param>
            public override void Post(SendOrPostCallback d, object state)
            {
                if (d == null) throw new ArgumentNullException("d");
                m_queue.Add(new KeyValuePair<SendOrPostCallback, object>(d, state));
            }

            /// <summary>Not supported.</summary>
            public override void Send(SendOrPostCallback d, object state)
            {
                throw new NotSupportedException("Synchronously sending is not supported.");
            }

            /// <summary>Runs an loop to process all queued work items.</summary>
            public void RunOnCurrentThread()
            {
                foreach (var workItem in m_queue.GetConsumingEnumerable())
                    workItem.Key(workItem.Value);
            }

            /// <summary>Notifies the context that no more work will arrive.</summary>
            public void Complete() { m_queue.CompleteAdding(); }

            /// <summary>Invoked when an async operation is started.</summary>
            public override void OperationStarted()
            {
                if (m_trackOperations)
                    Interlocked.Increment(ref m_operationCount);
            }

            /// <summary>Invoked when an async operation is completed.</summary>
            public override void OperationCompleted()
            {
                if (m_trackOperations &&
                    Interlocked.Decrement(ref m_operationCount) == 0)
                    Complete();
            }
        }
    }
}

Uso:

AsyncPump.Run(() => FooAsync(...));

Uma descrição mais detalhada da bomba assíncrona está disponível aqui .

Para quem mais prestar atenção a esta pergunta ...

Se você olhar, Microsoft.VisualStudio.Services.WebApihá uma classe chamada TaskExtensions. Dentro dessa classe, você verá o método de extensão estáticaTask.SyncResult() , que bloqueia totalmente o thread até que a tarefa retorne.

Internamente, ele chama, o task.GetAwaiter().GetResult()que é bastante simples, mas está sobrecarregado para funcionar em qualquer asyncmétodo que retorne Task, Task<T>ouTask<HttpResponseMessage> ... açúcar sintático, bebê ... papai tem um gosto por doces.

Parece que ...GetAwaiter().GetResult()é a maneira oficial da MS de executar código assíncrono em um contexto de bloqueio. Parece funcionar muito bem no meu caso de uso.

var result = Task.Run(async () => await configManager.GetConfigurationAsync()).ConfigureAwait(false);

OpenIdConnectConfiguration config = result.GetAwaiter().GetResult();

Ou use isto:

var result=result.GetAwaiter().GetResult().AccessToken

Você pode chamar qualquer método assíncrono a partir de código síncrono, ou seja, até precisar awaitdeles, caso em que eles também deverão ser marcados async.

Como muitas pessoas sugerem aqui, você pode chamar Wait () ou Result na tarefa resultante no seu método síncrono, mas então você acaba com uma chamada de bloqueio nesse método, o que meio que derrota o propósito da assíncrona.

Se você realmente não pode criar seu método asynce não deseja bloquear o método síncrono, precisará usar um método de retorno de chamada passando-o como parâmetro para o método ContinueWith na tarefa.

Eu sei que estou tão atrasada. Mas no caso de alguém como eu querer resolver isso de maneira organizada, fácil e sem depender de outra biblioteca.

Encontrei o seguinte trecho de código de Ryan

public static class AsyncHelpers
{
    private static readonly TaskFactory taskFactory = new
        TaskFactory(CancellationToken.None,
            TaskCreationOptions.None,
            TaskContinuationOptions.None,
            TaskScheduler.Default);

    /// <summary>
    /// Executes an async Task method which has a void return value synchronously
    /// USAGE: AsyncUtil.RunSync(() => AsyncMethod());
    /// </summary>
    /// <param name="task">Task method to execute</param>
    public static void RunSync(Func<Task> task)
        => taskFactory
            .StartNew(task)
            .Unwrap()
            .GetAwaiter()
            .GetResult();

    /// <summary>
    /// Executes an async Task<T> method which has a T return type synchronously
    /// USAGE: T result = AsyncUtil.RunSync(() => AsyncMethod<T>());
    /// </summary>
    /// <typeparam name="TResult">Return Type</typeparam>
    /// <param name="task">Task<T> method to execute</param>
    /// <returns></returns>
    public static TResult RunSync<TResult>(Func<Task<TResult>> task)
        => taskFactory
            .StartNew(task)
            .Unwrap()
            .GetAwaiter()
            .GetResult();
}

então você pode chamar assim

var t = AsyncUtil.RunSync<T>(() => AsyncMethod<T>());

Depois de horas tentando métodos diferentes, com mais ou menos sucesso, foi com isso que acabei. Ele não termina em um impasse ao obter resultado e também recebe e lança a exceção original e não a finalizada.

private ReturnType RunSync()
{
  var task = Task.Run(async () => await myMethodAsync(agency));
  if (task.IsFaulted && task.Exception != null)
  {
    throw task.Exception;
  }

  return task.Result;
}

Pode ser chamado de um novo encadeamento (NÃO do conjunto de encadeamentos!):

public static class SomeHelperClass
{ 
       public static T Result<T>(Func<T> func)
        {
            return Task.Factory.StartNew<T>(
                  () => func()
                , TaskCreationOptions.LongRunning
                ).Result;
        }
}
...
content = SomeHelperClass.Result<string>(
  () => response.Content.ReadAsStringAsync().Result
  );

Esses métodos assíncronos do Windows têm um pequeno método bacana chamado AsTask (). Você pode usar isso para que o método retorne como uma tarefa, para que você possa chamar manualmente Wait ().

Por exemplo, em um aplicativo Windows Phone 8 Silverlight, você pode fazer o seguinte:

private void DeleteSynchronous(string path)
{
    StorageFolder localFolder = Windows.Storage.ApplicationData.Current.LocalFolder;
    Task t = localFolder.DeleteAsync(StorageDeleteOption.PermanentDelete).AsTask();
    t.Wait();
}

private void FunctionThatNeedsToBeSynchronous()
{
    // Do some work here
    // ....

    // Delete something in storage synchronously
    DeleteSynchronous("pathGoesHere");

    // Do other work here 
    // .....
}

Espero que isto ajude!

Se você deseja executá-lo Sync

MethodAsync().RunSynchronously()

   //Example from non UI thread -    
   private void SaveAssetAsDraft()
    {
        SaveAssetDataAsDraft();
    }
    private async Task<bool> SaveAssetDataAsDraft()
    {
       var id = await _assetServiceManager.SavePendingAssetAsDraft();
       return true;   
    }
   //UI Thread - 
   var result = Task.Run(() => SaveAssetDataAsDraft().Result).Result;