Почему использование .Result в ASP. NET Core не приводит к тупику? - PullRequest
Новая
       4

Почему использование .Result в ASP. NET Core не приводит к тупику?

2 голосов
/ 03 марта 2020

Я прочитал эту статью , и, насколько я понимаю, вызов .Result для Задачи, полученной из асинхронного c метода, должен привести к взаимоблокировке одного из действий контроллера.

У меня есть следующий код, по которому я пытался воспроизвести то, что должно было вести себя как тупик: 

// GET api/values
[HttpGet]
public ActionResult<string> Get()
{
    return GetSomeValue().Result.ToString();
}

private async Task<JObject> GetSomeValue()
{
    using (var httpClient = new HttpClient())
    {
        var jsonString = await httpClient.GetStringAsync("https://localhost:44316/api/values");
        return JObject.Parse(jsonString);
    }
}

На https://localhost:44316/api/values у меня есть другое веб-приложение, которое просто возвращает мне действительный json .

Код работает безупречно, хотя, как указано в статье, он должен привести к тупику, так как продолжение метода GetStringAsync должно ожидать контекст ASP. NET, который следует удерживать. по первому методу Get (поток запросов).

Почему я не могу воспроизвести тупик, описанный в статье, чего мне не хватает?

1 Ответ

4 голосов
/ 03 марта 2020

В статье говорится о поведении определенного syn c контекста в ASP .NET; это не относится к. NET Core вообще, и даже в ASP. NET это было изменено в более поздние времена на то, что более симпатично c к TPL, но я подозреваю, что если вы конфигурируете ASP. NET (не «Core») с помощью: 

<add key="aspnet:UseTaskFriendlySynchronizationContext" value="false" />

или: 

<httpRuntime targetFramework="4.5" />

, тогда вы увидите обсуждаемое поведение.

Однако! Вы все еще не должны делать то, что делаете ; это ужасная идея получить доступ к .Result, если вы не знаете задача выполнена; await является предпочтительным механизмом. То, что в данном случае не взорвется , не означает, что это нормально.

...