受到其他一些答案的启发，我创建了以下简单的帮助方法:

public static TResult RunSync<TResult>(Func<Task<TResult>> method)
{
    var task = method();
    return task.GetAwaiter().GetResult();
}

public static void RunSync(Func<Task> method)
{
    var task = method();
    task.GetAwaiter().GetResult();
}

调用方法如下(取决于你是否返回值):

RunSync(() => Foo());
var result = RunSync(() => FooWithResult());

注意，原始问题public async void Foo()中的签名是不正确的。它应该是公共async Task Foo()，因为对于不返回值的异步方法，应该返回Task而不是void(是的，有一些罕见的例外)。

public async Task<string> StartMyTask()
{
    await Foo()
    // code to execute once foo is done
}

static void Main()
{
     var myTask = StartMyTask(); // call your method which will return control once it hits await
     // now you can continue executing code here
     string result = myTask.Result; // wait for the task to complete to continue
     // use result

}

您将‘await’关键字读为“启动这个长时间运行的任务，然后将控制权返回给调用方法”。长时间运行的任务完成后，它将执行后面的代码。await之后的代码类似于过去的CallBack方法。最大的区别是逻辑流没有中断，这使得读写更容易。

async Main现在是c# 7.2的一部分，可以在项目的高级构建设置中启用。

对于c# < 7.2，正确的方法是:

static void Main(string[] args)
{
   MainAsync().GetAwaiter().GetResult();
}


static async Task MainAsync()
{
   /*await stuff here*/
}

你会在很多微软文档中看到这个用法，例如: https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-dotnet-how-to-use-topics-subscriptions

如果你想运行它同步

MethodAsync().RunSynchronously()

斯蒂芬·克利里的回答;

这种方法应该不会导致死锁(假设 ProblemMethodAsync不发送更新到UI线程或任何东西 像这样)。它假设可以在对象上调用ProblemMethodAsync 线程池线程，这并不总是这样。

https://blog.stephencleary.com/2012/07/dont-block-on-async-code.html

这就是方法;

线程池攻击与阻塞攻击类似的方法是 将异步工作卸载到线程池，然后阻塞 产生的任务。使用此黑客的代码看起来像下面的代码 如图7所示。 图7线程池攻击的代码 c#

public sealed class WebDataService : IDataService
{
  public string Get(int id)
  {
    return Task.Run(() => GetAsync(id)).GetAwaiter().GetResult();
  }
  public async Task<string> GetAsync(int id)
  {
    using (var client = new WebClient())
      return await client.DownloadStringTaskAsync(
      "https://www.example.com/api/values/" + id);
  }
}

Task的调用。Run在线程池上执行异步方法 线程。在这里，它将在没有上下文的情况下运行，从而避免 死锁。这种方法的一个问题是异步性 方法不能依赖于在特定上下文中执行。所以,它 不能使用UI元素或ASP。净HttpContext.Current。

异步编程的确是通过代码库“增长”的。它被比作僵尸病毒。最好的解决办法是让它成长，但有时这是不可能的。

我在我的Nito中写了一些类型。用于处理部分异步代码库的AsyncEx库。然而，没有一种解决方案适用于所有情况。

解决方案一

如果您有一个简单的异步方法，不需要同步回上下文，那么您可以使用Task。WaitAndUnwrapException:

var task = MyAsyncMethod();
var result = task.WaitAndUnwrapException();

您不想使用Task。等待或任务。结果，因为它们在AggregateException中包装了异常。

该解决方案仅适用于MyAsyncMethod不同步回上下文的情况。换句话说，MyAsyncMethod中的每个await都应该以ConfigureAwait(false)结束。这意味着它不能更新任何UI元素或访问ASP。NET请求上下文。

解决方案B

如果MyAsyncMethod需要同步回它的上下文，那么你可以使用AsyncContext。RunTask提供一个嵌套的上下文:

var result = AsyncContext.RunTask(MyAsyncMethod).Result;

*更新4/14/2014:在库的最新版本中，API如下:

var result = AsyncContext.Run(MyAsyncMethod);

(可以使用Task。因为RunTask将传播Task异常)。

你可能需要AsyncContext的原因。RunTask而不是Task。WaitAndUnwrapException是由于在WinForms/WPF/SL/ASP上可能会发生相当微妙的死锁。NET:

A synchronous method calls an async method, obtaining a Task. The synchronous method does a blocking wait on the Task. The async method uses await without ConfigureAwait. The Task cannot complete in this situation because it only completes when the async method is finished; the async method cannot complete because it is attempting to schedule its continuation to the SynchronizationContext, and WinForms/WPF/SL/ASP.NET will not allow the continuation to run because the synchronous method is already running in that context.

这就是为什么在每个异步方法中尽可能使用ConfigureAwait(false)是一个好主意的原因之一。

解决方案C

AsyncContext。RunTask并不适用于所有场景。例如，如果异步方法等待需要UI事件才能完成的事情，那么即使嵌套上下文也会死锁。在这种情况下，你可以在线程池上启动async方法:

var task = Task.Run(async () => await MyAsyncMethod());
var result = task.WaitAndUnwrapException();

但是，这个解决方案需要在线程池上下文中工作的MyAsyncMethod。所以它不能更新UI元素或访问ASP。NET请求上下文。在这种情况下，您也可以将ConfigureAwait(false)添加到它的await语句中，并使用解决方案A。

更新日期:2019-05-01:当前的“最不坏的做法”见MSDN的一篇文章。