Editar: esta pregunta parece que podría ser el mismo problema, pero no tiene respuestas ...

Editar: en el caso de prueba 5, la tarea parece estar atascada en el WaitingForActivationestado.

Me encontré con un comportamiento extraño al usar System.Net.Http.HttpClient en .NET 4.5, donde "esperar" el resultado de una llamada a (por ejemplo) httpClient.GetAsync(...)nunca volverá.

Esto solo ocurre en ciertas circunstancias cuando se usa la nueva funcionalidad de lenguaje asíncrono / espera y la API de tareas: el código siempre parece funcionar cuando se usan solo continuaciones.

Aquí hay un código que reproduce el problema: colóquelo en un nuevo "proyecto MVC 4 WebApi" en Visual Studio 11 para exponer los siguientes puntos finales GET:

/api/test1
/api/test2
/api/test3
/api/test4
/api/test5 <--- never completes
/api/test6

Cada uno de los puntos finales aquí devuelve los mismos datos (los encabezados de respuesta de stackoverflow.com) excepto /api/test5que nunca se completa.

¿Me he encontrado con un error en la clase HttpClient, o estoy haciendo un mal uso de la API de alguna manera?

Código para reproducir:

public class BaseApiController : ApiController
{
    /// <summary>
    /// Retrieves data using continuations
    /// </summary>
    protected Task<string> Continuations_GetSomeDataAsync()
    {
        var httpClient = new HttpClient();

        var t = httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead);

        return t.ContinueWith(t1 => t1.Result.Content.Headers.ToString());
    }

    /// <summary>
    /// Retrieves data using async/await
    /// </summary>
    protected async Task<string> AsyncAwait_GetSomeDataAsync()
    {
        var httpClient = new HttpClient();

        var result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead);

        return result.Content.Headers.ToString();
    }
}

public class Test1Controller : BaseApiController
{
    /// <summary>
    /// Handles task using Async/Await
    /// </summary>
    public async Task<string> Get()
    {
        var data = await Continuations_GetSomeDataAsync();

        return data;
    }
}

public class Test2Controller : BaseApiController
{
    /// <summary>
    /// Handles task by blocking the thread until the task completes
    /// </summary>
    public string Get()
    {
        var task = Continuations_GetSomeDataAsync();

        var data = task.GetAwaiter().GetResult();

        return data;
    }
}

public class Test3Controller : BaseApiController
{
    /// <summary>
    /// Passes the task back to the controller host
    /// </summary>
    public Task<string> Get()
    {
        return Continuations_GetSomeDataAsync();
    }
}

public class Test4Controller : BaseApiController
{
    /// <summary>
    /// Handles task using Async/Await
    /// </summary>
    public async Task<string> Get()
    {
        var data = await AsyncAwait_GetSomeDataAsync();

        return data;
    }
}

public class Test5Controller : BaseApiController
{
    /// <summary>
    /// Handles task by blocking the thread until the task completes
    /// </summary>
    public string Get()
    {
        var task = AsyncAwait_GetSomeDataAsync();

        var data = task.GetAwaiter().GetResult();

        return data;
    }
}

public class Test6Controller : BaseApiController
{
    /// <summary>
    /// Passes the task back to the controller host
    /// </summary>
    public Task<string> Get()
    {
        return AsyncAwait_GetSomeDataAsync();
    }
}

Estás haciendo un mal uso de la API.

Aquí está la situación: en ASP.NET, solo un hilo puede manejar una solicitud a la vez. Puede hacer un procesamiento paralelo si es necesario (tomar prestados subprocesos adicionales del grupo de subprocesos), pero solo un subproceso tendría el contexto de solicitud (los subprocesos adicionales no tienen el contexto de solicitud).

Esto es administrado por ASP.NETSynchronizationContext .

Por defecto, cuando awaita Task, el método se reanuda en un capturado SynchronizationContext(o un capturado TaskScheduler, si no hay SynchronizationContext). Normalmente, esto es justo lo que desea: una acción de controlador asíncrono será awaitalgo y, cuando se reanude, se reanudará con el contexto de la solicitud.

Entonces, aquí está el por qué test5falla:

• Test5Controller.Getse ejecuta AsyncAwait_GetSomeDataAsync(dentro del contexto de solicitud ASP.NET).
• AsyncAwait_GetSomeDataAsyncse ejecuta HttpClient.GetAsync(dentro del contexto de solicitud ASP.NET).
• La solicitud HTTP se envía y HttpClient.GetAsyncdevuelve un mensaje incompleto.Task .
• AsyncAwait_GetSomeDataAsyncespera el Task; ya que no está completo, AsyncAwait_GetSomeDataAsyncdevuelve un incompleto Task.
• Test5Controller.Get bloquea el hilo actual hasta queTask complete.
• La respuesta HTTP entra y se completa la Taskdevolución de HttpClient.GetAsync.
• AsyncAwait_GetSomeDataAsyncintenta reanudar dentro del contexto de solicitud ASP.NET. Sin embargo, ya hay un hilo en ese contexto: el hilo bloqueado Test5Controller.Get.
• Punto muerto.

He aquí por qué funcionan los otros:

• ( test1, test2y test3): Continuations_GetSomeDataAsyncprograma la continuación del grupo de subprocesos, fuera del contexto de solicitud ASP.NET. Esto permite que el Taskdevuelto se Continuations_GetSomeDataAsynccomplete sin tener que volver a ingresar el contexto de la solicitud.
• ( test4y test6): como Taskse espera , el subproceso de solicitud ASP.NET no está bloqueado. Esto permiteAsyncAwait_GetSomeDataAsync usar el contexto de solicitud ASP.NET cuando está listo para continuar.

Y aquí están las mejores prácticas:

1. En sus asyncmétodos de "biblioteca" , use ConfigureAwait(false)siempre que sea posible. En su caso, esto cambiaría AsyncAwait_GetSomeDataAsyncpara servar result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead).ConfigureAwait(false);
2. No bloquees en Tasks; está asynctodo el camino hacia abajo. En otras palabras, use en awaitlugar de GetResult( Task.Resulty Task.Waittambién debe reemplazarse por await).

De esa manera, obtienes ambos beneficios: la continuación (el resto del AsyncAwait_GetSomeDataAsync método) se ejecuta en un subproceso de grupo de subprocesos básico que no tiene que ingresar el contexto de solicitud ASP.NET; y el controlador en sí es async(que no bloquea un hilo de solicitud).

Más información:

• Mi publicación async/ awaitintroducción , que incluye una breve descripción de cómo Taskusan los camarerosSynchronizationContext .
• El Async / Await FAQ , que entra en más detalles sobre los contextos. ¡También vea Await, y UI, y deadlocks! ¡Oh mi! lo que se aplica aquí aunque esté en ASP.NET en lugar de una interfaz de usuario, porque ASP.NETSynchronizationContext restringe el contexto de solicitud a solo un hilo a la vez.
• Esta publicación del foro de MSDN .
• Stephen Toub muestra este punto muerto (usando una interfaz de usuario) , y también lo hace Lucian Wischik .

Actualización 2012-07-13: incorporó esta respuesta en una publicación de blog .

Editar: generalmente trate de evitar hacer lo siguiente, excepto como un último esfuerzo para evitar puntos muertos. Lea el primer comentario de Stephen Cleary.

Solución rápida desde aquí . En lugar de escribir:

Task tsk = AsyncOperation();
tsk.Wait();

Tratar:

Task.Run(() => AsyncOperation()).Wait();

O si necesitas un resultado:

var result = Task.Run(() => AsyncOperation()).Result;

Desde la fuente (editado para que coincida con el ejemplo anterior):

AsyncOperation ahora se invocará en ThreadPool, donde no habrá un SynchronizationContext, y las continuaciones utilizadas dentro de AsyncOperation no se verán obligadas a volver al hilo de invocación.

Para mí, esto parece una opción útil ya que no tengo la opción de hacerlo asíncrono todo el tiempo (lo que preferiría).

De la fuente:

Asegúrese de que la espera en el método FooAsync no encuentre un contexto para volver a ordenar. La forma más sencilla de hacerlo es invocar el trabajo asincrónico desde el ThreadPool, como envolviendo la invocación en una tarea.

int Sync () {return Task.Run (() => Library.FooAsync ()). Resultado; }

FooAsync ahora se invocará en ThreadPool, donde no habrá un SynchronizationContext, y las continuaciones utilizadas dentro de FooAsync no se verán obligadas a volver al hilo que invoca Sync ().

Dado que está utilizando .Resulto .Waito awaitesto terminará causando un punto muerto en su código.

puede usar ConfigureAwait(false)en asyncmétodos para prevenir el punto muerto

Me gusta esto:

var result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead)
                             .ConfigureAwait(false);

puede usar ConfigureAwait(false)siempre que sea posible para No bloquear el código asincrónico.

Estas dos escuelas no son realmente excluyentes.

Aquí está el escenario donde simplemente tienes que usar

   Task.Run(() => AsyncOperation()).Wait(); 

o algo así

   AsyncContext.Run(AsyncOperation);

Tengo una acción MVC que está bajo el atributo de transacción de base de datos. La idea era (probablemente) revertir todo lo hecho en la acción si algo sale mal. Esto no permite el cambio de contexto, de lo contrario, la reversión o confirmación de transacción fallará.

La biblioteca que necesito es asíncrona, ya que se espera que se ejecute de forma asíncrona.

La unica opcion. Ejecútelo como una llamada de sincronización normal.

Solo digo a cada uno lo suyo.

Voy a poner esto aquí más por completo que por relevancia directa para el OP. Pasé casi un día depurando una HttpClientsolicitud, preguntándome por qué nunca recibiría una respuesta.

Finalmente descubrí que había olvidado awaitla asyncllamada más abajo en la pila de llamadas.

Se siente tan bien como perder un punto y coma.

Estoy mirando aqui:

http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.taskawaiter(v=vs.110).aspx

Y aquí:

http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.taskawaiter.getresult(v=vs.110).aspx

Y viendo:

Este tipo y sus miembros están destinados a ser utilizados por el compilador.

Teniendo en cuenta que la awaitversión funciona y es la forma "correcta" de hacer las cosas, ¿realmente necesita una respuesta a esta pregunta?

Mi voto es: mal uso de la API .