serilog | Simple .NET logging with fully-structured events

Just remove

You can use UseSerilogRequestLogging like below to add custom properties like Username and IPAddress. You should add it after UseAuthentication to get logged in Username.

You don't have to use another ILogger to inject separately. Serilog handles it by itself. Just use sub-loggers and add some WriteTo.Logger . Then you can use ILogger somewhere inside your code and it automatically saves logs according to your configuration.

For example:

If you refer to the Provided Sinks list and examine the source code for some of them, you'll notice that the pattern is usually:

1. Construct the sink configuration (usually taking values from IConfiguration, inline or a combination of both)
2. Pass the configuration to the sink registration.

Then the sink implementation instantiates the required services to push logs to.

An alternate approach I could suggest is registering Serilog without any arguments (UseSerilog()) and then configure the static Serilog.Log class using the built IServiceProvider:

Add try/catch similar to the above around IHostBulder.Build() in any .NET/EF Core 6.0 RC2 project, and attempt to add a migration can reproduce the issue.

We can fix the issue with the following :

As alluded to in the comment from @Daniel A. White, you are doing a risky thing -- trying to write to a file, in a handler that's provided on an "if all else fails" basis. Some examples:

• if the disk is full and the File Logger can't write (File sinks dont necessarily do that, but if they wanted to communicate failure, it would be via the SelfLog)
• if a message string is malformed (Serilog logging calls will never throw; this is based on a fundamental tenet in the wiki about the logging not being important enough to stop a working app from working)

While the Serilog debugging and diagnostics Wiki page currently shows an example of writing to a file, that's simply not the nature of the contract -- it must not fail.

Hence, if you actually want to emit the SelfLog to a file, you will need to add a try/catch and swallow the exception in the handler.

I would say its pretty questionable value to have a file as a backup when the File Sink is your primary output. This is doubly the case as you don't have any mechanism to ensure it gets trimmed (imagine you had a tight loop logging with a malformed message string - it would fill your disk eventually).

I personally have handled this tradeoff by echoing the SelfLog to my Console Sink (which logging won't throw, per the above) on the basis that the operating environment (think Kubernetes) can be trusted to capture it, or alert.

If you are using NLog the easiest way to log in you startup.cs is to add private property.

Your main app(Primary app- 1st) uses any appsettings.json and you need to use the same file in the called console app(Secondary app - 2nd).

You can call the 2nd with args

1. The settings file from de primary program
Located for example in "C:\appsettings.json"

When you do Log.Logger = loggerConfig.CreateLogger(); you are configuring the global static Serilog.Log object. It will work as long as you call it via Log.Write() etc.

Your problem starts from the fact that, in your worker, I'm guessing you're using an injected ILogger<>. This will inject an MS ILogger. Unfortunately you have not told the MS ILogger to use serilog.

Linking the two should be straightforward (as per the instructions); you just tell the host builder you want to use Serilog: