How to properly write a custom Task returning method

Question

For running code asynchronously (eg with async/await) I need a proper Task. Of course there are several predefined methods in the framework which cover the most frequent operations, but sometimes I want to write my own ones. I’m new to C# so it’s quite possible that I’m doing it wrong but I’m at least not fully happy with my current practice. See the following example for what I’m doing:

public async Task<bool> doHeavyWork()
    {
        var b1 = await this.Foo();
        //var b2 = await Task<bool>.Factory.StartNew(Bar); //using Task.Run
        var b2 =  await Task.Run(()=>Bar());
        return b1 & b2;
    }

public Task<bool> Foo()
    {
        return Task.Factory.StartNew(() =>
                                  {
                                      //do a lot of work without awaiting
                                      //any other Task
                                      return false;
                                  });
    }

public bool Bar()
    {
        //do a lot of work without awaiting any other task
        return false;
    }

In general I create and consume such methods like the Foo example, but there is an ‘extra’ lambda containing the whole method logic which doesn't look very pretty imho. Another option is to consume any Method like the Bar example, however I think that’s even worse because it isn’t clear that this method should be run async (apart from proper method names like BarAsync) and the Task.Factory.StartNew may has to be repeated several times in the program. I don’t know how to just tell the compiler ‘this method returns a Task, please wrap it as a whole into a Task when called’ which is what I want to do.

Finally my question: What’s the best way to write such a method? Can I get rid of the ‘extra’ lambda (without adding an additional named method of course)?

EDIT As Servy stated there is always good reason to have a synchronous version of the method. An async version should be provided only if absolutley necessary (Stephen Cleary's link).

Answer 1

Would the world end if someone wanted to call Bar without starting it in a new thread/Task? What if there is another method that is already in a background thread so it doesn't need to start a new task to just run that long running code? What if the method ends up being refactored into a class library that is called from both desktop app context as well as an ASP or console context? In those other contexts that method would probably just need to be run directly, not as a Task.

I would say your code should look like Bar does there, unless it's absolutely imperative that, under no circumstances whatsoever, should that code be run without starting a new Task.

Also note that with newer versions of .NET you should be switching from Task.Factory.StartNew to Task.Run, so the amount of code should go down (a tad).