C# 在WinRT中，为什么从同步上下文调用Task.Result会阻止我的应用程序

我参与了将一些代码移植到Windows应用商店库的工作。 有时，我们可以在继续之前等待异步操作的结果，这样会比较方便。我以为我们已经用Task的Result属性找到了答案，但由于某种原因，它使我的应用程序崩溃了

我制作了一个快速Windows应用商店测试应用程序，如下所示：

public MainPage()
{
    this.InitializeComponent();
    MyTextBox.Text = "0";
    var a = ReturnIntMax();
    MyTextBox.Text = "1";
    MyTextBox.Text = a.Result.ToString();
}

public async Task<int> ReturnIntMax()
{
    await Task.Delay(1000);
    return 5;
}

public主页（）
{
this.InitializeComponent（）；
MyTextBox.Text=“0”；
var a=ReturnIntMax（）；
MyTextBox.Text=“1”；
MyTextBox.Text=a.Result.ToString（）；
}
公共异步任务ReturnIntMax（）
{
等待任务。延迟（1000）；
返回5；
}

就我所理解的结果属性而言，这应该是可行的，所以我希望有人能告诉我发生了什么。我对这为什么是糟糕的设计不感兴趣。我们正在处理大量的通信流量，我们不能允许冲突。如果有必要，我们可以解决这个问题，但首先我想了解为什么它不起作用。如果只是不支持从同步上下文调用结果，我会认为这会给我一个编译器错误。

我在我的博客上描述了。这不是一个编译器错误，有几个原因；e、 例如，要求编译器（负责将C#翻译成IL）理解各种用户界面框架的线程模型违反了关注点分离。此外，在UI线程上为每个调用

Result

添加错误也是不实际的

---

一般来说，不要使用

Task.Wait

或

Task.Result

。相反，找到一种方法来构造代码，使其异步。这可能会很尴尬，但最终你会发现你最终得到了更好的UI设计（即，在加载主页时，你需要设计一个空白或“加载…”页面，可以立即显示，然后转换为显示数据，而不是阻塞UI）。我的博客发表了一些关于如何使它们

异步

-友好的想法。

或者@Kiewic当然。OP问的是为什么代码会阻塞，而不是如何修复它。

SynchronizationContext

的问题是按照代码最初的结构描述的，有两个线程，一个用于UI，一个用于处理所有通信流量的逻辑。在大多数情况下，comm通信线程同步运行是很重要的，这似乎需要在代码中添加wait命令。