What is NLog?

• NLog is a free and open source library which helps to write log messages.

Why should I use NLog? I can just do file.WriteLine() or Console.WriteLine()

• Beside writing to files or console, then NLog can also write to many other targets, like database, email, event viewer, trace etc.
• Output can be written in standard formats like Json / Csv / Xml or simple plain text with support for structured logging
• The output can be customized to include extra context like ${threadid} with help from Layout Renderers.
• NLog can use background threads for asynchronous output writing, so application threads are less impacted by logging.
• On-the-fly changing of the logging-configuration without needing to restart or redeploy. Configuration can be changed at runtime from code or by updating the configuration file. Updating the LogLevel filtering or the output targets.

Is it free?

• Yes, it's licensed under the BSD license, so you can use it in commercial (closed source) programs without problems.

Show me the magic!

• Check the tutorial to get started!

Just show me a config example

• voilà

Why is NLog not working?!

• Most problems are fixed by following the troubleshooting guide. If you think it's a bug, please check contributing.md and create a GitHub issue!

Is NLog thread safe?

• Yes NLog provides thread safety:
  • Creating new Logger is threadsafe
  • Writing LogEvents is threadsafe
  • Updating context containers like GDC / ScopeContext is threadsafe
  • Adding new LoggingRules or Targets using LoggingConfiguration.AddRule and ReconfigExistingLoggers is threadsafe
  • Performing Reload of LoggingConfiguration will cause LogEvents from active loggers to be dropped until reload has completed.
  • Changing values of existing rules and targets at run-time isn't thread-safe!

Why is trace and debug logs missing in ASP.NET Core?

• Check your appsettings.json

Should I use Microsoft Extensions Logging?

• That's up to you. It has it pros and cons. The greatest advantage is that you can easily switch between logging implementations (NLog, Log4Net, etc). This can be very important if you’re writing a library yourself, then the user who's using your library can choose which implementation to use.

• There are some downsides:

  • You are limited in some features, or some features aren't available at all or harder to access.
  • The performance is a bit lower.

• See also NLog GetCurrentClassLogger vs Microsoft ILogger

When a library depends on NLog, what version of NLog should be used?

• If you don't use the latest additions, then you should only update every NLog major version. Since NLog 4.0 the assembly version is fixed to 4.0.0.0 and because follow semver. The end-user don't need <assemblybinding>-magic! So in short: your library should target NLog 4.0 and in the future NLog 5.0.

How to properly log exceptions?

How to log extra Context Information?

How do I get the most optimal performance?

How to handle environment specific configuration?

How to load NLog configuration from non standard path?

How to create NLog Logger for sub classes?

How to create isolated NLog Logger for Addons and Plugins?

How to wrap NLog Logger?

How do I write custom Targets, layouts and layout renderers?

How to do dependency injection with NLog?

How could I combine programmatic configuration with XML configuration?