IWebHostBuilder.Configure() not executing in ASP.NET Core - asp.net-core

Why is that a call to IWebHostBuilder.Configure() extension method seemingly doesn't do anything in ASP.NET Core (experienced in version 3.4.0)?
For example in this scenario:
public static IHostBuilder CreateHostBuilder(string[] args)
=> Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder => {
webBuilder
.UseSerilog( ... )
.Configure(appBuilder => // Doesn't do anything.
appBuilder.UseSerilogRequestLogging( ... ))
.UseStartup<Startup>();
});
Here, UseSerilogRequestLogging() is called inside Configure() to add Serilog's request logging middleware before Startup executes, in order to place it at the beginning of the request pipeline, and also to keep logging-related configuration at one place.
But Configure() literally doesn't do anything, and the middleware is not added.

The reason is that the IWebHostBuilder.Configure() method is not just a general configuration method. It actually registers the provided delegate as IStartup in the ServiceCollection. See source (albeit old) here.
This means that when UseStartup<Startup>() is called subsequently, it replaces the previously registered delegate, and thus the configuration in Configure() is not executed.
This behavior can be further confirmed if you place Configure() after UseStartup<>(). In this case, Configure() will be the one that replaces UseStartup<>(), and UseStartup() won't execute.
The documentation on Configure() method actually hints at this:
//
// Summary:
// Specify the startup method to be used to configure the web application.
//
(Answered my own question, to spare some time for someone else who might end up being as perplexed as I was.)

Related

ILogger in Asp.net Core and Serilog

I have a question,
Is there any concern if I use ILogger in Serilog on behalf of Microsoft logger?
public void ConfigureServices(IServiceCollection services)
{
services.AddSingleton(Log.Logger);
}
Then use from ILogger in Serilog namespace.
_logger.Error(exception, "Error", exception.Message, exceptionId);
What is your idea?
Microsoft.Extensions.ILogger is an abstraction that decouples your application code (the code that writes log entries) from the underlying logging framework.
Using this abstraction brings the benefit, that you could easily change the Logging Framework underneath (e.g. replace Serilog with NLog) and don't have to update all references in your application code.
Also using Microsoft's abstractions also allows you to configure logging of your application code and logging of Microsoft SDKs you might use at a single place.
The downside of abstractions is that you have to aggree to a common minimum interface provided by all logging frameworks. It's not so easy to use Framework-Specific features this way.
So most of the time i would advise using the abstraction.
If you have very specific features from Serilog you would like to interact with you could think about using ILogger from Serilog directly.
However you can configure serilog in the provider registration as well to a high degree and probably get the best of both worlds.
You would configure Serilog factory interface to be used instead of built-in Logger factory for creating ILogger
First in program.cs, add the Serilog ILoggerFactory to your IHostBuilder with UserSerilog() method in CreateHostBuilder():
public static IHostBuilder CreateHostBuilder(string[] args) =>
new HostBuilder()
.ConfigureHostConfiguration(builder => { /* Host configuration */ })
.ConfigureAppConfiguration(builder => { /* App configuration */ })
.ConfigureServices(services => { /* Service configuration */})
.UseSerilog(); // <- Add this line
}
How the library works behind the scenes
On the face of it, completely replacing the default ASP.NET Core logging system to use a different one seems like a big deal. Luckily, thanks to the use of interfaces, loose coupling, and dependency injection, the code is remarkably simple! The whole extension method we used previously is shown below:
public static class SerilogHostBuilderExtensions
{
public static IHostBuilder UseSerilog(this IHostBuilder builder,
Serilog.ILogger logger = null, bool dispose = false)
{
builder.ConfigureServices((context, collection) =>
collection.AddSingleton<ILoggerFactory>(services => new
SerilogLoggerFactory(logger, dispose)));
return builder;
}
}
The UseSerilog() extension calls the ConfigureServices method on the IHostBuilder and adds an instance of the SerilogLoggerFactory as the application's ILoggerFactory. Whenever an ILoggerFactory is required by the app (to create an ILogger), the SerilogLoggerFactory will be used.
for more Information check this Link
"The downside of abstractions is that you have to aggree to a common minimum interface provided by all logging frameworks. It's not so easy to use Framework-Specific features this way."
I think we can always create extension methods to overcome this downside.

Loading different piece of configuration every request

I have an app where I'd like to load different config sections based on a header coming from the request
Here is part of my startup.cs
public void ConfigureServices(IServiceCollection services)
{
services.AddControllers();
IConfiguration cfg = null;
services.AddScoped<IConfiguration>(x =>
{
cfg = Configuration.GetSection("AppSettings:" + x.GetService<IHttpContextAccessor>()?.HttpContext?.Request?.Headers["xxx"]);
return (cfg);
});
services.AddSingleton<DB.Calendar.Repo>(x => new DB.Calendar.Repo(cfg));
services.AddApplicationInsightsTelemetry();
}
Problem is nothing inside the lambda of AddScoped gets called at all (even if I just put some console.outs) so cfg stays null. What am I doing wrong
The delegate passed to services.AddScoped() is only executed when a new scope is created (i.e. at the start of a HTTP request for ASP.NET apps). Which explains why cfg is null when AddSingleton() is called.
Something like this should work:
services.AddScoped<DB.Calendar.Repo>(x => {
var cfg = Configuration.GetSection("AppSettings:" + x.GetService<IHttpContextAccessor>()?.HttpContext?.Request?.Headers["xxx"]);
return new DB.Calendar.Repo(cfg);
});
Once you've got it working, it'd be wise to move the logic that reads the correct configuration section to its own service, to make it more testable (and also make it look clean).

ASP.net Core 2.2 configuration

Coming from a webforms background, I'm trying to understand how configuration and environment translation works in .net core 2.2 MVC web apps. Gone are the web.config files and the ConfigurationSettings.AppSettings property. I'm finding the documentation a little unclear.
The documentation states I need to call AddJsonFile or AddXmlFile during application startup. Like this:
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.ConfigureAppConfiguration((hostingContext, config) =>
{
config.SetBasePath(Directory.GetCurrentDirectory());
config.AddJsonFile(
"config.json", optional: true, reloadOnChange: true);
})
.UseStartup<Startup>();
The project template I use already has the following logic:
public static void Main(string[] args)
{
CreateWebHostBuilder(args).Build().Run();
}
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>();
My project has appsettings.json and appsettings.development.json files. When I put a breakpoint on the Startup method of the Startup class, I can inspect the configuration parameter and see the two json configuration files exposed as what looks to be a dictionary.
Questions
So do I have to explicitly call AddJSonFile, or is this actually done for me somehow by the framework?
How do I handle transforming configuration for different deployments?
What is the best way to access this configuration in a controller?
So do I have to explicitly call AddJSonFile, or is this actually done for me somehow by the framework?
This is done in the framework. Most notably the "DefaultBuilder" adds in both appsettings.json and appsettings.{Environment}.json, among other things. https://learn.microsoft.com/en-us/dotnet/api/microsoft.aspnetcore.webhost.createdefaultbuilder?view=aspnetcore-2.2
How do I handle transforming configuration for different deployments?
You need to set the Environment variable on the host machine (This is the easiest way althought here are other ways to do it). So for example if you set the environment to be Production, then it will first load appsettings.json, then it will load appsettings.Production.json and override the default settings. More info here : https://dotnetcoretutorials.com/2017/05/03/environments-asp-net-core/
What is the best way to access this configuration in a controller?
There are two ways. You can use the Options pattern built into the framework : https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options?view=aspnetcore-2.2
Or you can use good old fashioned POCO's (https://dotnetcoretutorials.com/2016/12/26/custom-configuration-sections-asp-net-core/).
All you need to do there is load out your configuration in your ConfigureServices method and bind it to a singleton :
services.AddSingleton(Configuration.GetSection("myConfiguration").Get<MyConfiguration>());
Then you can simply request it in your controller via DI:
public class ValuesController : Controller
{
private readonly MyConfiguration _myConfiguration;
public ValuesController(MyConfiguration myConfiguration)
{
_myConfiguration = myConfiguration;
}
}

Getting Hub Context for ASPNet.Core Signal-R (.NET Core 2.1) RC

I'm using ASP.NET Core 2.1 RC1.
I'm also using Signal-R for it (found here):
https://learn.microsoft.com/en-us/aspnet/core/signalr/javascript-client?view=aspnetcore-2.1
I'm creating a .NET Core console application that's hosting Kestrel and using Signal-R. I've pretty much set it up exactly as the getting started documentation states for setting up the Startup.
This all works great. I'm able to connect to the it, get my HTML with signal-R script in it, receive messages I crafted with Clients.All.SendAsync. Works great.
BUT
I want to be able to send a message to clients, from outside the Hub. Where some event happens in my application, and a message is sent to clients. In full .NET, I'd use the GlobalHost and get the context. In ALL my searches on Stack Overflow, they reference something that no longer works, or used within an REST API controller that's passed in the IHubContext.
I have an event listener in my program.cs, and when the event is triggered, I'd love to be able to send a message to my UserInterfaceHub.
So -- how do I get the hub context in Program.CS - so I can send messages to it (call the SwitchUI method) from within an event delegate I have in Program.CS?
StartUp.cs
public void ConfigureServices(IServiceCollection services) {
services.Configure<CookiePolicyOptions>(options => {
options.CheckConsentNeeded = context => true;
options.MinimumSameSitePolicy = SameSiteMode.None;
});
services.AddMvc();
services.AddCors(options => options.AddPolicy("CorsPolicy",
builder => {builder.AllowAnyMethod().AllowAnyHeader().AllowAnyOrigin().AllowCredentials();}));
services.AddSignalR();
var provider = services.BuildServiceProvider();
}
public void Configure(IApplicationBuilder app, IHostingEnvironment env) {
if (env.IsDevelopment()) app.UseDeveloperExceptionPage();
app.UseStaticFiles();
app.UseCookiePolicy();
app.UseCors("CorsPolicy");
app.UseSignalR(routes => {routes.MapHub<UserInterfaceHub>("/uihub");});
app.UseMvc();
//app.Run(async (context) =>{await context.Response.WriteAsync("Active");});
}
Program.CS
CreateWebHostBuilder(args)
.UseKestrel()
.UseUrls("http://0.0.0.0:" + appProperties.HostPort.ToString().Trim())
.UseContentRoot(Directory.GetCurrentDirectory())
.UseIISIntegration()
.Build()
.Start();
UserInterfaceHub.cs
namespace InterfaceModule.Hubs {
public class UserInterfaceHub : Hub {
public async Task SwitchUI(string message) {
await Clients.All.SendAsync("ReceiveEvent", message);
}
public override async Task OnConnectedAsync() {
//await SwitchUI("HOWDY NEW PERSON!");
await base.OnConnectedAsync();
}
}
}
edit adding clarity.
In Program.CS, I have this event delegate:
//now that we're ready, start listening.
await
deviceClient.SetInputMessageHandlerAsync(ModuleProperties.InputName, OnReceiveEvent, deviceClient);
Console.WriteLine("INIT: Event Message Input handler created: [{0}]", ModuleProperties.InputName);
which is this:
static async Task<MessageResponse> OnReceiveEvent(Message message, object userContext) {
//HOW DO I REACH THE HUB FROM HERE SO I CAN SEND A MESSAGE TO THE LISTENERS?
}
I encountered a similar situation and here's how to resolve it:
In your Service layer, create an interface called something like ISendHubMessage. Have a method called Send() that takes parameters that you're wanting to send via SignalR. Create a class within the same file called SendHubMessage that implements the interface. Have it just do a return.
In your top-level project (where your Startup.cs file is located) create another class called SendHubMessage that implements that same ISendHubMessage interface from your Service layer. Within this SendHubMessage, you can use DI to get at the hub as explained above. This method will do the actual logic of sending via SignalR.
In your Startup ConfigureServices() method, add the following line:
services.AddTransient<"Service".ISendHubMessage, "TopLevel".SendHubMessage>();
(where "Service" is the namespace to your Service-level project and "TopLevel" in the namespace to your top-level project).
What you're doing with this line is saying "Whenever an object requests the ISendHubMessage dependency from the Service layer, supply it with the SendHubMessage class defined in my top-level project".
Finally, in all the places in code outside of your top-level project that you're wanting to send messages through your hub, inject that ISendHubMessage dependency in the constructor. You can then refer to it in the class methods and when you call Send(), it will call the Send() method defined in your SendHubMessage class in your top-level project.
This line of code:
app.UseSignalR(routes => {routes.MapHub<UserInterfaceHub>("/uihub");});
will register your hub with the DI container. Then to get access to it, you either use constructor injection to inject in the IHubContext<UserInterfaceHub> (this works for example in a Web Controller) or access it directly from the DI container by doing the following:
var hub = app.ApplicationServices.GetRequiredService<IHubContext<UserInterfaceHub>>();
(for example if executed in the startup.cs Configure method)
If you don't have access to the app.ApplicationServices which is basically an IServiceProvider at the location you need to access the hub, then you will need to either 1) get that class to work with dependency injection to inject in the IHubContext<UserInterfaceHub> or IServiceProvider 2) Setup a static Services global var via Configure so that you can have access to one of them globally, or find some other way to access the DI container (aka IServiceProvider) to get your hub via the above line of code.
Once you have your hub, then sending the message to the registered clients is a simple as calling the method on your hub.
await hub.Clients.All.SendAsync("ReceiveEvent", message);
You're question is a little unclear, but I'm assuming you mean you want to replace the following with something that can send a message through your hub:
app.Run(async (context) =>{await context.Response.WriteAsync("Active");});
Since this is in your Configure method, you can simply add IServiceCollection services to your Configure methods params. Then, you can do:
var hub = services.GetRequiredService<IHubContext<MyHub>>();
However, I'm not sure that this will actually do anything useful ultimately. At startup, you'd logically have no clients with subscriptions yet. As a result, sending a message through your hub at this point, would essentially go nowhere. By the time a user actually hits your site and gets connected to your hub, this part of your application has already run, and won't be hit again.

Hangfire does not log exception using configured Logger

As per the hangfire documentation
Starting from Hangfire 1.3.0, you are not required to do anything, if
your application already uses one of the following libraries through
the reflection (so that Hangfire itself does not depend on any of
them). Logging implementation is automatically chosen by checking for
the presence of corresponding types in the order shown below.
Serilog
NLog
Log4Net
EntLib
Logging
Loupe
Elmah
I have ASP.NET Core 2.0 application that is using Serilog like below
public class Program
{
public static void Main(string[] args)
{
BuildWebHost(args).Run();
}
public static IWebHost BuildWebHost(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.UseApplicationInsights()
.UseUrls("http://*:40006")
.ConfigureAppConfiguration((hostingContext, config) =>
{
// removed for bravity
})
.ConfigureLogging((hostingContext, logging) =>
{
Log.Logger = new LoggerConfiguration()
.ReadFrom.Configuration(hostingContext.Configuration)
.CreateLogger();
logging.AddSerilog();
})
.Build();
}
The application is configured to use Hangfire. During background job processing if there is any exception occurs, Hangfire re-tries the job 10 times with increasing delay as expected, and it shows the exceptions in dashboard.
Issue
The Hangfire dashboard shows the exception on UI however it does not log the exception into configured Serilog sink.
Note: The Hangfire dashboard shows exception but it formats the exception see here which hides critical information about the exception.
I think if it logs the exception, Serilog logger would log the complete exception.
I had the same issue with the latest Hangfire version using .NET Core 3.1.
The solution was to call the UseSerilogLogProvider() method of IGlobalConfiguration in StartUp.cs.
For example:
GlobalConfiguration.Configuration.UseSerilogLogProvider();
or
services.AddHangfire(configuration => configuration
.UseSimpleAssemblyNameTypeSerializer()
.UseRecommendedSerializerSettings()
.UseSerilogLogProvider());
Normally this call shouldn't be needed but there are some cases where automatic wiring isn't working (an example would be referencing multiple logging providers). You can read more about this in the official Hangfire documentation: Configure Logging