ConfigureAwait (true) в библиотеке

Question

У меня есть ASP. NET приложение WebForms, в котором есть страницы, использующие Async=True, и я использую RegisterAsyncTask(new PageAsyncTask(InitialiseAsync)); в моем OnLoad методе для асинхронного вызова бизнес-логики c.

Теперь я знаю, ASP. NET WebForms требует асин c вызовов, за которыми следует ConfigureAwait(true), так как он должен вернуться к исходному контексту синхронизации, чтобы завершить sh страницу. Однако цепочка вызовов asyn c переходит в библиотечную сборку (также созданную нами). Библиотека не должна ни знать, ни заботиться о syn c контекстах, чтобы выполнять свою асинхронную работу. Кроме того, его можно (потенциально) использовать в других контекстах, таких как консольное приложение.

Поэтому:

1. , если методы библиотеки всегда используют ConfigureAwait(true) (в случае, если оно используется контекстно-зависимым приложением, таким как ASP. NET Web Forms) ?; или
2. можно ли использовать методы библиотеки ConfigureAwait(false) и приложение WebForms ConfigureAwait(true) ?; или
3. (я уверен, что это не ответ, но ...) я должен передать в библиотеку логическое значение, указывающее, использовать ли ConfigureAwait(true) или ConfigureAwait(false)?

Я использовал опцию 1 до сих пор, но теперь я подозреваю, что мне следует использовать опцию 2, чтобы код библиотеки мог await вернуться в любой поток , и приложение в конечном итоге будет работать переключение контекста обратно в поток контекста required при возврате стека вызовов.

Это правильно? Спасибо

Answer 1

ConfigureAwait - это решение, которое нужно принять только для функции . Если указанная c функция должна вернуться в свой контекст, то она не должна использовать ConfigureAwait(false); в противном случае он может использовать его. Нужен ли контекст вызывающему контексту - неважно; когда его абонент await s, он может решить для себя, использовать ConfigureAwait(false) или нет. Таким образом, опция (3) никогда не должна использоваться.

Вы можете go с опцией (2), и это то, что я выбрал бы сейчас. ConfigureAwait(false) имеет некоторые преимущества. Тем не менее, в настоящее время наблюдается постоянный сдвиг во мнениях по этому вопросу, во многом обусловленный тем фактом, что ASP. NET Ядро не имеет контекста (поэтому ConfigureAwait(false) - это oop, и людям это не нравится это загромождает их код). Я все еще использую ConfigureAwait(false) в коде библиотеки, но некоторые другие разработчики полностью удалили ConfigureAwait(false) из своих библиотек. Это эквивалентно вашему варианту (1). Любой из этих вариантов будет работать; если производительность не имеет значения, она сводится к предпочтениям.