Попробуйте изменить подход и не пытаться внедрять IConfiguration
создать класс для хранения желаемых настроек
public class MyOptions {
public string MyDatabase { get; set; }
}
Измените настройку, чтобы также использовать ConfigureServices
и извлечьтребуемая конфигурация для заполнения объекта настроек и добавления его в коллекцию сервисов
var builder = new HostBuilder();
builder
.ConfigureWebJobs(b => {
b.AddAzureStorageCoreServices();
b.AddAzureStorage();
})
.ConfigureAppConfiguration(config => { //not using context so no need for it really
config.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true).Build();
config.AddEnvironmentVariables();
})
//...ADDITION HERE
.ConfigureServices((context, services) => {
//configuration should be available by now, so access what you need.
var connectionString = context.Configuration.GetConnectionString("MyDatabase");
//If null you have the option to fail early, otherwise carry on.
var myOptions = new MyOptions {
MyDatabase = connectionString;
};
services.AddSingeton(myOptions);
}
.ConfigureLogging((context, b) => {
b.AddConsole();
});
//...
Таким образом, на этом этапе вы сможете добавить свой объект в качестве зависимости к функции
public class Functions {
public static void ProcessQueueMessage(
[QueueTrigger("myqueue")] string message,
ILogger logger,
MyOptions options) {
logger.LogInformation(message);
logger.LogInformation(options.MyDatabase);
}
}
Лично я считаю, что попытка получить доступ к IConfiguration
вне стартапа доставляет больше хлопот, чем стоит, и даже оценила бы его с помощью анти-паттерна поиска сервисов и введения IServiceProvider
.Получите то, что вам нужно от него во время установки, зарегистрируйте это в сервис-коллекции, чтобы оно было доступно для внедрения там, где это необходимо.