RB
Сделай лучше)
Например отсюда https://devblogs.microsoft.com/oldnewthing/20190328-00/?p=102368
Изкоробочный вариант все обсуждают https://github.com/dotnet/runtime/issues/20025
А так то пул этот всегда есть
Size: a a a
2021 July 05
V
Я раньше всегда думал, что ConfigureAwait везде нужно писать, т.к. либа может использоваться и в приложении с кастомным контекстом синхронизации...
G
Как будто я первый, ога
https://github.com/dotnet/aspnetcore/issues/22688
И вот тут
Barry Dorrans blowdart
The .NET security person.
Короче видемо тот, чьих рук это дело, отписывается.
https://github.com/aspnet/Security/issues/1689
https://github.com/dotnet/aspnetcore/issues/22688
И вот тут
Barry Dorrans blowdart
The .NET security person.
Короче видемо тот, чьих рук это дело, отписывается.
https://github.com/aspnet/Security/issues/1689
AH
эта проблема с конфигур евейтом только в сишарпе. Не надо тут дотнет марать
AH
я бы не был так уверен!
Но да, зачастую фоди даже работает с фшарпом
Но да, зачастую фоди даже работает с фшарпом
A
A
это если ConfigureAwait(false) у тебя на незавершенной таске, а если завершилась - протекает дальше, поэтому и дальше надо фигачить ConfigureAwait(false).. либо использовать гарантированно незавершенную таску, которая контекст срывает
IC
Открою вам секрет! В 99 процентах случаев вам без разницы на configure await
A
На aspnetcore
IC
В остальных 0.9% случаях похуй на Легаси винформы и старый асп
IC
И только когда к вам в репу придёт Никита, тогда стоит подумать
IC
И даже в этом случае делать ничего не стоит
DP
Ага. А бизнес логику надо выделять отдельно чтобы зареюзать можно было и в десктопной версии и в мобильной и в бекенде
DP
И валидацию делать на регулярках чтобы их в бд запихать как check и на фронт