N1mm logger startup options code#

So in the factory you had above, instead of passing in an IConfiguration, you can ask for it from DI. To put it another way - IConfiguration is a singleton service registered with DI and you can access it from anywhere you could access IOptions. That IConfiguration should have all environment variables and app settings applied. You can use a factory to get the fully-resolved IConfiguration like I've shown above. One of the reasons we keep punting this issue is because for most scenarios, access to IConfiguration isn't required during startup and other issues with higher priorities keep moving above this one. No need to be patient :-) Let me know if it works for you - or if it's missing something you need.

N1mm logger startup options code#

The code I provided above is the right way to do this - it's not even a workaround. The host code that looks for an WebJobsStartupAttribute-annotated class would inspect the constructors of the startup class, and if there's a constructor that accepts an IConfiguration it should use that, passing the configuration, just like we get in ASP.NET Core apps. So what I'd really like is for functions to support the same pattern.

It makes it possible to make configuration-driven decisions about how you configure services at startup. If you look at a typical ASP.NET Core startup class, it takes an IConfiguration as a constructor argument, for precisely this reason. So what are you supposed to do if you need access to configuration settings as part of your service configuration code? The problem with the current design is that there doesn't seem to be a reliable way to get hold of the IConfiguration in your Startup.Configure method.Īpparently the only mechanism by which you can obtain IConfiguration is to have it injected as a dependency, which means it's only available after you've finished configuring all your services, and the service collection has been built.