Azure Функции могут принимать параметр ILogger
, который по умолчанию записывает в App Insights. У меня есть пользовательская ILoggerProvider
реализация, которую я тоже хочу зарегистрировать. Этот провайдер создает объединенные экземпляры моей пользовательской реализации ILogger
, которые отправляют журналы в мои Azure очереди. Моему провайдеру нужен доступ к параметрам конфигурации, поэтому я использую AddSingleton
трюк вместо AddProvider
:
[assembly: FunctionsStartup(typeof(Startup))]
public class Startup : FunctionsStartup
{
public override void Configure(IFunctionsHostBuilder builder)
{
// Initialize options.
builder.Services.AddLogging(loggingBuilder =>
{
loggingBuilder.Services.AddSingleton<MyCustomLoggerProvider>();
});
}
}
Однако теперь я столкнулся с другой проблемой , Моя регистрация требует некоторой асинхронной инициализации, чтобы установить sh соединение с целевой очередью (на уровне провайдера или на уровне регистратора). Обычно эту асинхронную инициализацию можно отложить до первого использования до AsyncLazy
; однако это требует, чтобы указанное использование также было асинхронным. В моем случае ILoggerProvider
и ILogger
являются встроенными интерфейсами, которые не имеют асинхронных методов, поэтому я не могу отложить асинхронную инициализацию.
Каков наилучший подход для решения этой проблемы? Есть ли способ регистрации зависимости, который требует асинхронной инициализации, но чей потребительский интерфейс не предоставляет никаких асинхронных методов?
Я знаю, что это может быть тривиально исправлено несколькими антипаттернами , такими как блокировка в асинхронной операции (.Wait()
или .Result
) или ожидании того, что потребители выполнят явную инициализацию (EnsureInitializedAsync()
), но я хочу избежать этого.