ASP.NET Core 3.0 doesn't support logging in the Startup constructor or Startup.ConfigureServices as referenced in the following;
create-logs-in-the-startup-class
After reading Christian Riedl's [solution](LoggerBuffered on StackOverflow I adopted it. Later you will see that it works well when I embed the asp.net webapp inside an Azure Function.
- Create an in-memory ILogger that buffers the logs until we can hand them over to the real ILogger.
- Defer any exception thrown before
Startup.Configure
to be thrown after we copy the in-memmory log to the real ILogger. - Only inject
IServiceProvider
intoStartup.Configure
as a means to get other services.
Dependency injects is built out after Startup.ConfigureServices
completes, so you can inject services into Startup.Configure
.
i.e.
public void Configure(IApplicationBuilder app, IWebHostEnvironment env, IMySuperDuperService msd, ILogger<Startup> logger)
{
}
This will blowup if an Exception is thrown in Startup.ConfigureServices
before IMySuperDuperService
was registered.
IServiceProvider
and ILogger<Startup>
will always be there, so just inject those and ask IServiceProvider
for your IMySuperDuperService
public void Configure(IApplicationBuilder app, IWebHostEnvironment env, IServiceProvider serviceProvider, ILogger<Startup> logger)
{
...
var mySuperDuperService = serviceProvider.GetRequiredService<IMySuperDuperService>();
...
}
When it comes to HTTP Trigger, I didn't want to learn another way to develop an app that was basically REST apis that required bearer token authorization. I use a technique that uses TestServer (of all things) to bridge the gap between request comming into the function and ultimately winding up being handled by a good ole asp.net core 3 app.
When it comes to logging, the azure function provides the initial logger which is turned into a LogProvider for the downstream asp.net core app.
Take a look at azFunc-logger where the shim is dotnetcore.azFunction.AppShim