var result = Task.Run(async () => await configManager.GetConfigurationAsync()).ConfigureAwait(false);

OpenIdConnectConfiguration config = result.GetAwaiter().GetResult();

或者用这个:

var result=result.GetAwaiter().GetResult().AccessToken

在尝试了几个小时不同的方法后，或多或少取得了成功，这就是我最终得到的结果。它在获取结果时不会以死锁结束，它还会获取并抛出原始异常，而不是被包装的异常。

private ReturnType RunSync()
{
  var task = Task.Run(async () => await myMethodAsync(agency));
  if (task.IsFaulted && task.Exception != null)
  {
    throw task.Exception;
  }

  return task.Result;
}

这是最简单的解决办法。我在网上的某个地方看到它，我不记得在哪里了，但我一直在成功地使用它。它不会死锁调用线程。

    void SynchronousFunction()
    {
        Task.Run(Foo).Wait();
    }

    string SynchronousFunctionReturnsString()
    {
        return Task.Run(Foo).Result;
    }

    string SynchronousFunctionReturnsStringWithParam(int id)
    {
        return Task.Run(() => Foo(id)).Result;
    }

您可以从同步代码中调用任何异步方法，直到您需要等待它们，在这种情况下，它们也必须被标记为异步。

正如很多人在这里建议的那样，您可以在同步方法中对结果任务调用Wait()或Result，但最终会在该方法中进行阻塞调用，这在某种程度上违背了异步的目的。

如果你真的不能让你的方法异步，你不想锁定同步方法，那么你将不得不使用一个回调方法，把它作为参数传递给任务上的ContinueWith()方法。

对于任何还在关注这个问题的人…

在微软。visualstudio。services。webapi中有一个叫TaskExtensions的类。在这个类中，你会看到静态扩展方法task . syncresult()，它会完全阻塞线程，直到任务返回。

在内部，它调用Task . getawaiter ().GetResult()，这是非常简单的，但是它重载工作在任何异步方法，返回Task, Task<T>或Task<HttpResponseMessage>…语法糖，宝贝…爸爸爱吃甜食。

getresult()是在阻塞上下文中执行异步代码的ms官方方式。似乎在我的用例中工作得很好。

微软构建了一个AsyncHelper(内部)类来作为同步运行Async。源代码如下所示:

internal static class AsyncHelper
{
    private static readonly TaskFactory _myTaskFactory = new 
      TaskFactory(CancellationToken.None, 
                  TaskCreationOptions.None, 
                  TaskContinuationOptions.None, 
                  TaskScheduler.Default);

    public static TResult RunSync<TResult>(Func<Task<TResult>> func)
    {
        return AsyncHelper._myTaskFactory
          .StartNew<Task<TResult>>(func)
          .Unwrap<TResult>()
          .GetAwaiter()
          .GetResult();
    }

    public static void RunSync(Func<Task> func)
    {
        AsyncHelper._myTaskFactory
          .StartNew<Task>(func)
          .Unwrap()
          .GetAwaiter()
          .GetResult();
    }
}

identity基类只有Async方法，为了将它们调用为Sync，有一些类的扩展方法看起来像这样(示例用法):

public static TUser FindById<TUser, TKey>(this UserManager<TUser, TKey> manager, TKey userId) where TUser : class, IUser<TKey> where TKey : IEquatable<TKey>
{
    if (manager == null)
    {
        throw new ArgumentNullException("manager");
    }
    return AsyncHelper.RunSync<TUser>(() => manager.FindByIdAsync(userId));
}

public static bool IsInRole<TUser, TKey>(this UserManager<TUser, TKey> manager, TKey userId, string role) where TUser : class, IUser<TKey> where TKey : IEquatable<TKey>
{
    if (manager == null)
    {
        throw new ArgumentNullException("manager");
    }
    return AsyncHelper.RunSync<bool>(() => manager.IsInRoleAsync(userId, role));
}

对于那些关心代码许可条款的人，这里有一个非常相似的代码链接(只是在线程上增加了对文化的支持)，其中有注释表明它是由微软授权的MIT。https://github.com/aspnet/AspNetIdentity/blob/master/src/Microsoft.AspNet.Identity.Core/AsyncHelper.cs

这与调用Task不一样吗?运行(async ()=> await AsyncFunc()).Result?说真的，微软现在不鼓励调用TaskFactory。StartNew，因为它们都是等效的，一个比另一个更可读。

绝对不是。

答案很简单

.Unwrap().GetAwaiter().GetResult() != .Result

首先

是任务。结果与.GetAwaiter.GetResult()?

其次，unwrap()会导致Task的设置不阻塞被包装的任务。

谁会问这个问题呢

这与调用Task不一样吗?运行(async ()=> await AsyncFunc()).GetAwaiter().GetResult()

那就得看情况了。

关于Task.Start()， Task.Run()和Task.Factory.StartNew()的使用

摘录:

的任务。Run使用taskcreateoptions。DenyChildAttach意思是子任务不能附加到父任务它使用TaskScheduler。默认值，这意味着在线程池中运行任务的线程将始终用于运行任务。 startnew使用TaskScheduler。Current表示当前线程的调度程序，它可能是TaskScheduler。违约但并非总是如此。

更多阅读:

指定同步上下文

ASP。NET Core SynchronizationContext

为了更加安全，像这样调用AsyncHelper不是更好吗?RunSync(async () => await AsyncMethod().ConfigureAwait(false));通过这种方式，我们告诉"内部"方法"请不要尝试同步到上层上下文并取消锁"

非常好的观点，就像大多数对象架构问题一样，这要视情况而定。

作为一个扩展方法，你想强迫绝对每个调用，还是让程序员使用该函数配置他们自己的异步调用?我可以看到call 3场景的用例;它很可能不是你在WPF中想要的，当然在大多数情况下是有意义的，但考虑到在ASP中没有上下文。Net Core如果你能保证它是ASP内部的。Net Core，那就无所谓了。