Acabo de recibir VS2012 y estoy tratando de manejarlo async.

Digamos que tengo un método que obtiene algún valor de una fuente de bloqueo. No quiero bloquear la persona que llama del método. Podría escribir el método para tomar una devolución de llamada que se invoca cuando llega el valor, pero como estoy usando C # 5, decido hacer que el método sea asíncrono para que las personas que llaman no tengan que lidiar con devoluciones de llamada:

// contrived example (edited in response to Servy's comment)
public static Task<string> PromptForStringAsync(string prompt)
{
    return Task.Factory.StartNew(() => {
        Console.Write(prompt);
        return Console.ReadLine();
    });
}

Aquí hay un método de ejemplo que lo llama. Si PromptForStringAsyncno fuera asíncrono, este método requeriría anidar una devolución de llamada dentro de una devolución de llamada. Con async, puedo escribir mi método de esta manera muy natural:

public static async Task GetNameAsync()
{
    string firstname = await PromptForStringAsync("Enter your first name: ");
    Console.WriteLine("Welcome {0}.", firstname);

    string lastname = await PromptForStringAsync("Enter your last name: ");
    Console.WriteLine("Name saved as '{0} {1}'.", firstname, lastname);
}

Hasta aquí todo bien. El problema es cuando llamo a GetNameAsync:

public static void DoStuff()
{
    GetNameAsync();
    MainWorkOfApplicationIDontWantBlocked();
}

El punto GetNameAsynces que es asíncrono. No quiero que se bloquee, porque quiero volver a MainWorkOfApplicationIDontWantBlocked lo antes posible y dejar que GetNameAsync haga lo suyo en segundo plano. Sin embargo, llamarlo de esta manera me da una advertencia del compilador en la GetNameAsynclínea:

Warning 1   Because this call is not awaited, execution of the current method continues before the call is completed. Consider applying the 'await' operator to the result of the call.

Soy perfectamente consciente de que "la ejecución del método actual continúa antes de que se complete la llamada". Ese es el punto del código asincrónico, ¿verdad?

Prefiero compilar mi código sin advertencias, pero no hay nada que "arreglar" aquí porque el código está haciendo exactamente lo que tengo la intención de hacer. Puedo deshacerme de la advertencia almacenando el valor de retorno de GetNameAsync:

public static void DoStuff()
{
    var result = GetNameAsync(); // supress warning
    MainWorkOfApplicationIDontWantBlocked();
}

Pero ahora tengo un código superfluo. Visual Studio parece comprender que me vi obligado a escribir este código innecesario, ya que suprime la advertencia normal de "valor nunca utilizado".

También puedo deshacerme de la advertencia envolviendo GetNameAsync en un método que no es asíncrono:

    public static Task GetNameWrapper()
    {
        return GetNameAsync();
    }

Pero ese es un código aún más superfluo. Entonces tengo que escribir código que no necesito o tolerar una advertencia innecesaria.

¿Hay algo sobre mi uso de async que esté mal aquí?

Si realmente no necesita el resultado, simplemente puede cambiar la GetNameAsyncfirma para devolver void:

public static async void GetNameAsync()
{
    ...
}

Considere ver la respuesta a una pregunta relacionada: ¿Cuál es la diferencia entre devolver vacío y devolver una Tarea?

Actualizar

Si necesita el resultado, puede cambiar el GetNameAsyncpara devolver, por ejemplo Task<string>:

public static async Task<string> GetNameAsync()
{
    string firstname = await PromptForStringAsync("Enter your first name: ");
    string lastname = await PromptForStringAsync("Enter your last name: ");
    return firstname + lastname;
}

Y úsalo de la siguiente manera:

public static void DoStuff()
{
    Task<string> task = GetNameAsync();

    // Set up a continuation BEFORE MainWorkOfApplicationIDontWantBlocked
    Task anotherTask = task.ContinueWith(r => {
            Console.WriteLine(r.Result);
        });

    MainWorkOfApplicationIDontWantBlocked();

    // OR wait for the result AFTER
    string result = task.Result;
}

Llego bastante tarde a esta discusión, pero también existe la opción de usar la #pragmadirectiva de preprocesador. Tengo un código asíncrono aquí y allá que explícitamente no quiero esperar en algunas condiciones, y no me gustan las advertencias y las variables no utilizadas como el resto de ustedes:

#pragma warning disable 4014
SomeMethodAsync();
#pragma warning restore 4014

El "4014"proviene de esta página de MSDN: Advertencia del compilador (nivel 1) CS4014 .

Vea también la advertencia / respuesta de @ ryan-horath aquí https://stackoverflow.com/a/12145047/928483 .

Se perderán las excepciones lanzadas durante una llamada asincrónica que no se espera. Para deshacerse de esta advertencia, debe asignar el valor de retorno de la tarea de la llamada asincrónica a una variable. Esto garantiza que tenga acceso a cualquier excepción lanzada, que se indicará en el valor de retorno.

Actualización para C # 7.0

C # 7.0 agrega una nueva característica, descartar variables: Descartes - Guía C # , que también puede ayudar a este respecto.

_ = SomeMethodAsync();

No soy particularmente aficionado a las soluciones que asignan la tarea a una variable no utilizada o que cambian la firma del método para devolver void. El primero crea código superfluo y no intuitivo, mientras que el segundo puede no ser posible si está implementando una interfaz o tiene otro uso de la función donde desea usar la Tarea devuelta.

Mi solución es crear un método de extensión de Task, llamado DoNotAwait () que no hace nada. Esto no solo suprimirá todas las advertencias, ReSharper o de otra manera, sino que hará que el código sea más comprensible e indicará a los futuros mantenedores de su código que realmente tenía la intención de que la llamada no fuera esperada.

Método de extensión:

public static class TaskExtensions
{
    public static void DoNotAwait(this Task task) { }
}

Uso:

public static void DoStuff()
{
    GetNameAsync().DoNotAwait();
    MainWorkOfApplicationIDontWantBlocked();
}

Editado para agregar: esto es similar a la solución de Jonathan Allen donde el método de extensión comenzaría la tarea si aún no se hubiera iniciado, pero prefiero tener funciones de un solo propósito para que la intención de la persona que llama sea completamente clara.

async void ¡ES MALO!

1. ¿Cuál es la diferencia entre devolver vacío y devolver una tarea?
2. https://jaylee.org/archive/2012/07/08/c-sharp-async-tips-and-tricks-part-2-async-void.html

Lo que sugiero es que ejecute explícitamente a Tasktravés de un método anónimo ...

p.ej

public static void DoStuff()
{
    Task.Run(async () => GetNameAsync());
    MainWorkOfApplicationIDontWantBlocked();
}

O si desea que se bloquee, puede esperar en el método anónimo

public static void DoStuff()
{
    Task.Run(async () => await GetNameAsync());
    MainWorkOfApplicationThatWillBeBlocked();
}

Sin embargo, si su GetNameAsyncmétodo tiene que interactuar con la interfaz de usuario o incluso cualquier cosa vinculada a la interfaz de usuario (WINRT / MVVM, lo estoy mirando), entonces se vuelve un poco más funky =)

Deberá pasar la referencia al despachador de la interfaz de usuario de esta manera ...

Task.Run(async () => await GetNameAsync(CoreApplication.MainView.CoreWindow.Dispatcher));

Y luego, en su método asíncrono, deberá interactuar con su UI o elementos vinculados a la UI que pensaron que el despachador ...

dispatcher.RunAsync(CoreDispatcherPriority.Normal, () => {  this.UserName = userName; });

Esto es lo que estoy haciendo actualmente:

SomeAyncFunction().RunConcurrently();

Donde RunConcurrentlyse define como ...

 /// <summary> 
 /// Runs the Task in a concurrent thread without waiting for it to complete. This will start the task if it is not already running. 
 /// </summary> 
 /// <param name="task">The task to run.</param> 
 /// <remarks>This is usually used to avoid warning messages about not waiting for the task to complete.</remarks> 
 public static void RunConcurrently(this Task task) 
 { 
     if (task == null) 
         throw new ArgumentNullException("task", "task is null."); 

     if (task.Status == TaskStatus.Created) 
         task.Start(); 
 } 

https://github.com/docevaad/Anchor/blob/master/Tortuga.Anchor/Tortuga.Anchor.source/shared/TaskUtilities.cs

https://www.nuget.org/packages/Tortuga.Anchor/

De acuerdo con el artículo de Microsoft sobre esta advertencia, puede resolverla simplemente asignando la tarea devuelta a una variable. A continuación se muestra una traducción del código proporcionado en el ejemplo de Microsoft:

    // To suppress the warning without awaiting, you can assign the 
    // returned task to a variable. The assignment doesn't change how
    // the program runs. However, the recommended practice is always to
    // await a call to an async method.
    // Replace Call #1 with the following line.
    Task delayTask = CalledMethodAsync(delay);

Tenga en cuenta que al hacer esto aparecerá el mensaje "La variable local nunca se usa" en ReSharper.

Aquí, una solución simple.

public static class TasksExtensions
{
    public static void RunAndForget(this Task task)
    {
    }
}

Saludos

Es su ejemplo simplificado el que causa el código superfluo. Normalmente, desearía utilizar los datos que se obtuvieron de la fuente de bloqueo en algún momento del programa, por lo que desearía recuperar el resultado para poder acceder a los datos.

Si realmente tiene algo que sucede totalmente aislado del resto del programa, async no sería el enfoque correcto. Simplemente comience un nuevo hilo para esa tarea.

¿Realmente quieres ignorar el resultado? como incluir ignorar cualquier excepción inesperada?

Si no es así, es posible que desee echar un vistazo a esta pregunta: enfoque Fire and Forget ,

Si no desea cambiar la firma del método para devolver void(ya que la devolución voidsiempre debe ser anulada ), puede usar la función Descartar C # 7.0+ como esta, que es un poco mejor que asignar a una variable (y debería eliminar la mayoría de los demás advertencias de herramientas de validación de fuente):

public static void DoStuff()
{
    _ = GetNameAsync(); // we don't need the return value (suppresses warning)
    MainWorkOfApplicationIDontWantBlocked();
}