在WinRT中，為什么從同步上下文中調用Task.Result會阻止我的應用程序

Question

我參與了將一些代碼移植到Windows應用商店庫的工作。 對於我們而言，有時可以等待異步操作的結果再繼續操作會很方便。 我以為我們有了Task的Result屬性的答案，但是由於某種原因，它使我的應用程序崩潰了。

我制作了一個快速的Windows Store測試應用程序，如下所示：

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;
}

據我了解Result屬性，它應該起作用，所以我希望有人可以告訴我發生了什么事。 我對為什么這是不好的設計不感興趣。 我們正在處理大量的通訊流量，我們不允許沖突。 如有必要，我們可以解決此問題，但首先我想了解為什么它不起作用。 如果只是不支持從同步上下文中調用Result，我會認為這會給我一個編譯器錯誤。

Answer 1

我在博客上描述了僵局的根本原因 。 由於多種原因，這不是編譯器錯誤。 例如，要求編譯器（負責將C＃轉換為IL）理解各種用戶界面框架的線程模型，這是關注點分離的違反。 另外，為可能在UI線程上的每個Result調用添加錯誤也是不切實際的。

通常，不要使用Task.Wait或Task.Result 。 相反，找到一種結構化代碼的方法，使其異步。 這可能很尷尬，但是最終您會發現您得到了更好的UI設計（即，不是在加載主頁時阻止UI，而是需要設計空白頁面或“正在加載...”頁面）可以立即顯示，然后過渡以顯示數據）。 我在有關構造函數和屬性的博客文章中提出了一些使它們async友好的想法。