Nsryjdtyk

I have some pretty stock standard code for a typical .NET Core 2+ program.cs. I'm mainly setting up Logging.

With the code below, it's not async/await and the following happens:

• Logging occurs during the startup process 100%.


• the CloseAndFlush(); occurs nearly instantly, before the rest of the app does stuff.


• No logging occurs in any controllers.

This is in part due to how Serilog works but that's not really the important bit, AFAIK.

The code steps right over return CreateWebHostBuilder(args).Build().RunAsync(); .. when I thought this is the part where it would be awaited by the caller? When I debug my app, it does await (hang) on that line ... until the app has completed starting up. Once it's ready to accept connections, it then returns back here ... and runs through .. which means it calls Log.CloseAndFlush() and then return Task.CompletedTask.

Buggy Code:

public static Task Main(string args)

{

    Log.Logger = new LoggerConfiguration()....CreateLogger();



    try

    {

        // awaits here until the app has 100% started, then continues.

        return CreateWebHostBuilder(args).Build().RunAsync();

    }

    catch (Exception exception)

    {

        Log.Logger.Fatal(exception, "Host terminated unexpectantly. Sadness :~(");

    }

    finally

    {

        // Ensure to flush and stop internal timers/threads before application-exit (Avoid segmentation fault on Linux)

        Log.CloseAndFlush();

    }



    return Task.CompletedTask;

}

Now changing this to async/await fixes everything. The code does correctly await on return CreateWebHostBuilder(args).Build().RunAsync(); .. and then the CloseAndFlush() is called when the app is closing/terminating.

    public static async Task Main<T>(string args) where T : class

    {

        Log.Logger = new LoggerConfiguration()....CreateLogger();



        try

        {

            // Correctly waits here until the app explodes or ctrl-c has been pressed.

            await CreateWebHostBuilder<T>(args).Build().RunAsync();

        }

        catch (Exception exception)

        {

            Log.Error(exception, "Stopped program because of an exception.");

        }



        Log.Debug("Finished shutting down app.");



        // Ensure to flush and stop internal timers/threads before application-exit (Avoid segmentation fault on Linux)

        Log.CloseAndFlush();

    }

Would returning a Task probably be only suitable if the method is only doing one async/await in it AND that is the last thing in the method?

Returning a Task¹ instead of awaiting it is your way of saying "there's nothing left for this method to do here"².

If that's not the case (as here, where you don't want your finally clause to run yet), you're not done. You need some way of running some code at a later point in time, but you've got nothing useful to do now. And that's precisely what await allows you to signal.

¹As Jonas mentions, this is exactly true for non-Task returns too.

²I'm ignoring the case when you take a Task from elsewhere, add a ContinueWith and return the resulting Task, because there you're using a different mechanism to ensure you get to run code later and it's not precisely "this method" that runs in the continuation.

Would returning a Task probably be only suitable if the method is only doing one async/await in it AND that is the last thing in the method?

Basically, yes. Returning the task as in your first snippet will let the finally block run as you leave the scope, just like any other return statement inside a try with an associated finally. And as commented by ckuri your catch block won't do what you want either, as it will not catch exceptions from the task, only from the setup in CreateWebHostBuilder itself.