CODEWITHSUNDEEP
c#.netasp.netlogging
jcollum
jcollum

Reputation: 46569

help me find a minimal-friction logging solution for asp.net apps

Let's say, for the sake of argument, that I have 30 asp.net web applications (and sites, blerg) that need to have a logging framework. My current solution is to use Enterprise Library Logging. Getting this going on a site involves the following steps:

  1. add references to two assemblies (EL Logging and Common)
  2. add code to Global.asax.cs for generic unhandled error trapping
  3. copy in enterpriseLibrary.config, copied from another app that already has logging
  4. copy in FileConfigurationSource.cs (which allows you to override the requirement for a hardcoded path to the enterpriseLibrary.config)
  5. change namespace in FileConfigurationSource.cs to the new project
  6. copy web.config sections from another project that are specific to EL (2 sections)
  7. change namespaces in web.config for EL in new project
  8. test and make sure it's working (usually by taking the database offline)

All of that is the friction that I'm talking about. That's a lot of violations of DRY if you ask me, especially in all the enterpriseLibrary.config settings. Ideally, adding logging would be a two step process -- that will help me get it adopted across the team.

I wonder if there's a logging solution for .net that doesn't have all these repetitions? All of them that I can find (log4net, nlog, EL Logging) seem to use this "every app has it's own configuration with plenty of repetition" pattern. Perhaps I'm missing something.

In practice, every one of our apps will have a logging solution that's 99% identical to the other ones. They will differ in where they store their logs and what the app is called. Is there a way to use one of the big three logging solutions that let's you set the logging behavior at a machine level or in a more centralized place? I realize that there are downsides to having a centralized logging configuration.

Also important: must be able to change logging level on the fly (no storing logging config in web.config, causing an app restart) and the logging must be configurable as part of a deployment (don't want an email to be sent on critical errors on the beta server). These two make using web.config transforms difficult since running a transform on a .config as part of your build that isn't a web.config is difficult.

Upvotes: 3

Views: 293

Answers (1)

Dan Abramov
Dan Abramov

Reputation: 268215

I found a perfect solution for a problem similar to yours.

I have ten console applications, two ASP .NET websites and three SharePoint webparts logging to a single directory, the logs being separated by date, application name, etc. The solution is very configurable and flexible and allows configuration changes on the fly.

All this glory was brought to life by NLog, which allows for a single configuration file being included from application-specific configuration files.

To be more specific, in our case each project contains individual NLog config that reads as:

<?xml version="1.0" encoding="utf-8" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      autoReload="true">
  <include file="PATH TO THE SHARED CONFIG" /> <!-- change this line -->
</nlog>

For web applications, individual NLog configuration can be read from:

  • standard web application file web.config
  • web.nlog located in the same directory as web.config
  • NLog.config in application’s directory
  • NLog.dll.nlog in a directory where NLog.dll is located

Shared configuration file can be placed anywhere ASP .NET process can read, and also has autoReload="true" which allows on-the-fly modifications. In our case, it defines different targets for log messages, such as email, log files in different directories, et cetera.

Upvotes: 1

Related Questions