Suprimiendo "advertencia CS4014: debido a que no se espera esta llamada, la ejecución del método actual continúa ..."

Este no es un duplicado de "Cómo llamar de forma segura a un método asíncrono en C # sin esperar" .

¿Cómo suprimo bien la siguiente advertencia?

advertencia CS4014: debido a que no se espera esta llamada, la ejecución del método actual continúa antes de que se complete la llamada. Considere aplicar el operador 'esperar' al resultado de la llamada.

Un simple ejemplo:

static async Task WorkAsync()
{
    await Task.Delay(1000);
    Console.WriteLine("Done!");
}

static async Task StartWorkAsync()
{
    WorkAsync(); // I want fire-and-forget 

    // more unrelated async/await stuff here, e.g.:
    // ...
    await Task.Delay(2000); 
}

Lo que probé y no me gustó:

static async Task StartWorkAsync()
{
    #pragma warning disable 4014
    WorkAsync(); // I want fire-and-forget here
    #pragma warning restore 4014
    // ...
}

static async Task StartWorkAsync()
{
    var ignoreMe = WorkAsync(); // I want fire-and-forget here
    // ...
}

Actualizado , dado que la respuesta original aceptada ha sido editada, he cambiado la respuesta aceptada a la que usa los descartes de C # 7.0 , ya que no creo que ContinueWithsea ​​apropiado aquí. Siempre que necesito registrar excepciones para operaciones de disparar y olvidar, utilizo un enfoque más elaborado propuesto por Stephen Cleary aquí .

Con C # 7 ahora puede usar descartes :

_ = WorkAsync();

Puede crear un método de extensión que evitará la advertencia. El método de extensión puede estar vacío o puede agregar manejo de excepciones .ContinueWith()allí.

static class TaskExtensions
{
    public static void Forget(this Task task)
    {
        task.ContinueWith(
            t => { WriteLog(t.Exception); },
            TaskContinuationOptions.OnlyOnFaulted);
    }
}

public async Task StartWorkAsync()
{
    this.WorkAsync().Forget();
}

Sin embargo, ASP.NET cuenta el número de tareas en ejecución, por lo que no funcionará con la Forget()extensión simple como se enumeró anteriormente y en su lugar puede fallar con la excepción:

Un módulo o controlador asincrónico completado mientras una operación asincrónica aún estaba pendiente.

Con .NET 4.5.2 se puede resolver usando HostingEnvironment.QueueBackgroundWorkItem:

public static Task HandleFault(this Task task, CancellationToken cancelToken)
{
    return task.ContinueWith(
        t => { WriteLog(t.Exception); },
        cancelToken,
        TaskContinuationOptions.OnlyOnFaulted,
        TaskScheduler.Default);
}

public async Task StartWorkAsync()
{
    System.Web.Hosting.HostingEnvironment.QueueBackgroundWorkItem(
        cancelToken => this.WorkAsync().HandleFault(cancelToken));
}

Puede decorar el método con el siguiente atributo:

[System.Diagnostics.CodeAnalysis.SuppressMessage("Await.Warning", "CS4014:Await.Warning")]
static async Task StartWorkAsync()
{
    WorkAsync();
    // ...
}

Básicamente le está diciendo al compilador que sabe lo que está haciendo y que no necesita preocuparse por posibles errores.

La parte importante de este código es el segundo parámetro. La parte "CS4014:" es lo que suprime la advertencia. Puedes escribir lo que quieras sobre el resto.

Mis dos formas de lidiar con esto.

Guárdelo en una variable de descarte (C # 7)

Ejemplo

_ = Task.Run(() => DoMyStuff()).ConfigureAwait(false);

Desde la introducción de los descartes en C # 7, ahora considero que esto es mejor que suprimir la advertencia. Porque no solo suprime la advertencia, sino que también deja clara la intención de disparar y olvidar.

Además, el compilador podrá optimizarlo en modo de lanzamiento.

Solo suprímalo

#pragma warning disable 4014
...
#pragma warning restore 4014

es una buena solución para "disparar y olvidar".

La razón por la que existe esta advertencia es porque, en muchos casos, no es su intención utilizar un método que devuelva la tarea sin esperarla. Suprimir la advertencia cuando tiene la intención de disparar y olvidar tiene sentido.

Si tiene problemas para recordar cómo se deletrea #pragma warning disable 4014, simplemente deje que Visual Studio lo agregue por usted. Presione Ctrl +. para abrir "Acciones rápidas" y luego "Suprimir CS2014"

Considerándolo todo

Es estúpido crear un método que requiera unos cuantos ticks más para ejecutarse, solo con el propósito de suprimir una advertencia.

Una manera fácil de detener la advertencia es simplemente asignar la Tarea al llamarla:

Task fireAndForget = WorkAsync(); // No warning now

Y así en tu publicación original harías:

static async Task StartWorkAsync()
{
    // Fire and forget
    var fireAndForget = WorkAsync(); // Tell the compiler you know it's a task that's being returned 

    // more unrelated async/await stuff here, e.g.:
    // ...
    await Task.Delay(2000); 
}

El motivo de la advertencia es que WorkAsync está devolviendo un mensaje Taskque nunca se lee ni se espera. Puede establecer el tipo de retorno de WorkAsync voidy la advertencia desaparecerá.

Normalmente, un método devuelve un Taskcuando la persona que llama necesita saber el estado del trabajador. En el caso de disparar y olvidar, se debe devolver el vacío para que parezca que la persona que llama es independiente del método llamado.

static async void WorkAsync()
{
    await Task.Delay(1000);
    Console.WriteLine("Done!");
}

static async Task StartWorkAsync()
{
    WorkAsync(); // no warning since return type is void

    // more unrelated async/await stuff here, e.g.:
    // ...
    await Task.Delay(2000); 
}

¿Por qué no envolverlo dentro de un método asíncrono que devuelve vacío? Un poco largo pero se usan todas las variables.

static async Task StartWorkAsync()
{   
     async void WorkAndForgetAsync() => await WorkAsync();
     WorkAndForgetAsync(); // no warning
}

Encontré este enfoque por accidente hoy. Puede definir un delegado y asignar primero el método asíncrono al delegado.

    delegate Task IntermediateHandler();



    static async Task AsyncOperation()
    {
        await Task.Yield();
    }

y lo llaman así

(new IntermediateHandler(AsyncOperation))();

...

Pensé que era interesante que el compilador no diera exactamente la misma advertencia al usar el delegado.