Logging is an essential part of the application, especially in the case when you want to monitor traffic communicating with an external client that is having some problems connecting to your site.
Let's say a very obscure error is happening with regard to third-party software you are using, and the software provider is asking you for a log.
So, the solution is simple, add a logging component like NLog and log to a file by configuring the nlog.config file. But many times, it's not as simple as that.
What if your application is a multi-tenant deployment, and what if you can't modify nlog.config or appsettings.json after the deployment is done, and you need to temporarily enable the Debug logging or any temporary logging for that matter?
If we just add an NLog to the multi-tenant application with five clients, then all five clients will start writing logs in the same location, be it a file or a database. And what if the deployed code is not possible to modify (like a read-only zipped version)?
There is a solution for all of the above. NLog libraries provide all the necessary features to resolve all of the above problems.
The best part is that NLog allows you to use a new instance of NLog per each request and allows you to modify it just for this scope (per request).
Let's address the issues one by one.
To start, we are going to use a middleware to set the NLog in a generic manner.
In it, we will set all the dynamic properties specific to the tenant. In my case, they are
a DB connection string; logger filters for specific libraries (like Microsoft,ThirdPartyLib,Nlog.API, and everything(*))
In the Nlog.config file, we set the logger like the following code (please note mdlc:Nlog_mainDebug). This is the only way to modify the logger dynamically - by using 'filters' tag.