¿Cómo llamar al método asincrónico desde el método sincrónico en C #?

Tengo un public async void Foo()método al que quiero llamar desde un método sincrónico. Hasta ahora, todo lo que he visto en la documentación de MSDN es llamar a métodos asincrónicos a través de métodos asincrónicos, pero todo mi programa no está construido con métodos asincrónicos.

¿Es esto posible?

Aquí hay un ejemplo de llamar a estos métodos desde un método asincrónico: http://msdn.microsoft.com/en-us/library/hh300224(v=vs.110).aspx

Ahora estoy buscando llamar a estos métodos asincrónicos desde métodos de sincronización.

La programación asincrónica "crece" a través de la base de código. Se ha comparado con un virus zombie . La mejor solución es permitir que crezca, pero a veces eso no es posible.

He escrito algunos tipos en mi biblioteca Nito.AsyncEx para tratar con una base de código parcialmente asíncrono. Sin embargo, no hay una solución que funcione en cada situación.

Solución A

Si tiene un método asincrónico simple que no necesita sincronizarse de nuevo a su contexto, puede usar Task.WaitAndUnwrapException:

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

Usted no desea utilizar Task.Waito Task.Resultporque se envuelven en excepciones AggregateException.

Esta solución solo es apropiada si MyAsyncMethodno se sincroniza de nuevo con su contexto. En otras palabras, cada awaiten MyAsyncMethoddebe terminar con ConfigureAwait(false). Esto significa que no puede actualizar ningún elemento de la interfaz de usuario ni acceder al contexto de solicitud de ASP.NET.

Solución B

Si MyAsyncMethodnecesita sincronizarse nuevamente con su contexto, entonces puede usarlo AsyncContext.RunTaskpara proporcionar un contexto anidado:

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

* Actualización 14/04/2014: en versiones más recientes de la biblioteca, la API es la siguiente:

var result = AsyncContext.Run(MyAsyncMethod);

(Está bien usarlo Task.Resulten este ejemplo porque RunTaskpropagará Taskexcepciones).

La razón que puede necesitar en AsyncContext.RunTasklugar de esto Task.WaitAndUnwrapExceptionse debe a la posibilidad de un punto muerto bastante sutil que ocurre en WinForms / WPF / SL / ASP.NET:

1. Un método síncrono llama a un método asíncrono, obteniendo a Task.
2. El método sincrónico hace una espera de bloqueo en el Task.
3. El asyncmétodo usaawait sin ConfigureAwait.
4. No se Taskpuede completar en esta situación porque solo se completa cuando finaliza el asyncmétodo; el asyncmétodo no puede completarse porque está intentando programar su continuación para elSynchronizationContext , y WinForms / WPF / SL / ASP.NET no permitirá que se ejecute la continuación porque el método síncrono ya se está ejecutando en ese contexto.

Esta es una de las razones por las cuales es una buena idea usar lo más posible ConfigureAwait(false)en cada asyncmétodo.

Solución C

AsyncContext.RunTaskNo funcionará en todos los escenarios. Por ejemplo, si el asyncmétodo espera algo que requiera que se complete un evento de IU, entonces estará en punto muerto incluso con el contexto anidado. En ese caso, puede iniciar el asyncmétodo en el grupo de subprocesos:

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

Sin embargo, esta solución requiere una MyAsyncMethodque funcione en el contexto del grupo de subprocesos. Por lo tanto, no puede actualizar los elementos de la interfaz de usuario ni acceder al contexto de solicitud de ASP.NET. Y en ese caso, también puede agregar ConfigureAwait(false)a sus awaitdeclaraciones y usar la solución A.

Actualización, 01/05/2019: Las "prácticas menos peores" actuales se encuentran en un artículo de MSDN aquí .

Agregar una solución que finalmente resolvió mi problema, con suerte ahorrará el tiempo de alguien.

Primero lea un par de artículos de Stephen Cleary :

• Asíncrono y aguardar
• No bloquear en código asíncrono

De las "dos mejores prácticas" en "No bloquear en código asíncrono", la primera no funcionó para mí y la segunda no era aplicable (básicamente si puedo usar await , lo hago!).

Así que aquí está mi solución: envuelva la llamada dentro de Task.Run<>(async () => await FunctionAsync());y, con suerte, sin punto muerto .

Aquí está mi 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;
    }
}

Microsoft creó una clase AsyncHelper (interna) para ejecutar Async como Sync. La fuente se ve así:

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();
    }
}

Las clases base Microsoft.AspNet.Identity solo tienen métodos Async y para llamarlas como Sync hay clases con métodos de extensión similares (ejemplo 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 aquellos preocupados por los términos de licencia del código, aquí hay un enlace a un código muy similar (solo agrega soporte para la cultura en el hilo) que tiene comentarios para indicar que tiene licencia MIT de Microsoft. https://github.com/aspnet/AspNetIdentity/blob/master/src/Microsoft.AspNet.Identity.Core/AsyncHelper.cs

async Main ahora forma parte de C # 7.2 y se puede habilitar en la configuración de compilación avanzada del proyecto.

Para C # <7.2, la forma correcta es:

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


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

Verá esto usado en mucha documentación de Microsoft, por ejemplo: https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-how-to-use- temas-suscripciones

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

}

Lee la palabra clave 'esperar' como "iniciar esta tarea de ejecución prolongada y luego devolver el control al método de llamada". Una vez que se realiza la tarea de larga duración, se ejecuta el código después. El código después de la espera es similar a lo que solían ser los métodos de CallBack. La gran diferencia es que el flujo lógico no se interrumpe, lo que hace que sea mucho más fácil escribir y leer.

No estoy 100% seguro, pero creo que la técnica descrita en este blog debería funcionar en muchas circunstancias:

Por lo tanto, puede usar task.GetAwaiter().GetResult()si desea invocar directamente esta lógica de propagación.

Sin embargo, hay una buena solución que funciona en (casi: ver comentarios) en cada situación: una bomba de mensajes ad-hoc (SynchronizationContext).

El subproceso de llamada se bloqueará como se esperaba, a la vez que se asegurará de que todas las continuas llamadas desde la función asincrónica no se bloqueen, ya que se ordenarán al SynchronizationContext ad-hoc (bomba de mensajes) que se ejecuta en el subproceso de llamada.

El código del asistente de bomba de mensajes 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(...));

Una descripción más detallada de la bomba asíncrona está disponible aquí .

Para cualquiera que esté prestando atención a esta pregunta ...

Si miras adentro Microsoft.VisualStudio.Services.WebApihay una clase llamada TaskExtensions. Dentro de esa clase verás el método de extensión estáticaTask.SyncResult() , que simplemente bloquea el hilo hasta que la tarea regrese.

Internamente llama, lo task.GetAwaiter().GetResult()cual es bastante simple, sin embargo, está sobrecargado para funcionar en cualquier asyncmétodo que regrese Task, Task<T>oTask<HttpResponseMessage> ... azúcar sintáctica, bebé ... papá tiene un gusto por lo dulce.

Parece que ...GetAwaiter().GetResult()es la forma oficial de MS de ejecutar código asíncrono en un contexto de bloqueo. Parece funcionar muy bien para mi caso de uso.

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

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

O usa esto:

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

Puede llamar a cualquier método asincrónico desde un código síncrono, es decir, hasta que lo necesite await, en cuyo caso también deben marcarse async.

Como muchas personas están sugiriendo aquí, puede llamar a Wait () o Result en la tarea resultante en su método sincrónico, pero luego termina con una llamada de bloqueo en ese método, que de alguna manera anula el propósito de async.

Si realmente no puede hacer su método asyncy no desea bloquear el método sincrónico, entonces tendrá que usar un método de devolución de llamada pasándolo como parámetro al método ContinueWith en la tarea.

Sé que llego muy tarde. Pero en caso de que alguien como yo quisiera resolver esto de una manera ordenada, fácil y sin depender de otra biblioteca.

Encontré el siguiente 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();
}

entonces puedes llamarlo así

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

Después de horas de probar diferentes métodos, con más o menos éxito, esto es con lo que terminé. No termina en un punto muerto mientras se obtiene el resultado y también obtiene y lanza la excepción original y no la envuelta.

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

  return task.Result;
}

Podría llamarse desde un nuevo hilo (¡NO desde el grupo de hilos!):

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
  );

Esos métodos asincrónicos de Windows tienen un pequeño método ingenioso llamado AsTask (). Puede usar esto para que el método se devuelva como una tarea, de modo que pueda llamar manualmente a Wait () en él.

Por ejemplo, en una aplicación de Windows Phone 8 Silverlight, puede hacer lo siguiente:

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 esto ayude!

Si quieres ejecutarlo, sincroniza

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;