C# Logging. What should I use? [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

I'm looking at switching to a new unified logging solution for use in our new line of products and I wanted to see what some of the people on Stack Overflow thought. We will need logging for a variety of applicatons: ASP .net, windows services, web services, wpf apps etc. We are a windows shop only.

Some of our requirements for a logging solution include:

1) Log file management

- Ability to split files up over a certain size
- Ability to auto archive/delete after certain period of time

2) Ability to send emails on certain types of messages logged (errors for example)

3) Ability to write messages to the windows event log

- We need to be able to specify where it's being written in the event log. 
  It would also be nice if it would automatically create the event log source if it does exist.

I've started looking at nLog, windows trace and log4n开发者_如何学编程et. I'm not limited to these 3 only it's just a few that came up a lot when searching.

log4net is always a good choice.

http://logging.apache.org/log4net/

Use .NET common logging. You can choose later a specific provider (NLog, CLog, log4net...), or even create custom ones.

And just another one: NLog.

Files – single file or multiple, with automatic file naming and archival

Event Log – local or remote Database – store your logs in databases supported

by .NET Network – using TCP, UDP, SOAP, MSMQ protocols

Command-line console – including color coding of messages

E-mail – you can receive emails whenever application errors occur

ASP.NET trace

and many more

You can take a look at Enterprise Library, they have an application block for logging which is extensible

http://entlib.codeplex.com/

http://entlib.codeplex.com/releases/view/46741

you can download the dev guide pdf, they have a section on logging (Chapter 4)

See this question for another comprehensive answer: When should I use Tracing vs Logger.NET, Enterprise Library, log4net or Ukadc.Diagnostics?

In short, the main logging frameworks available are the built-in .NET Framework System.Diagnostics, log4net, NLog and Enterprise Library Logging Application Block.

A comparison of these main frameworks is available at: https://essentialdiagnostics.codeplex.com/wikipage?title=Comparison

1) Log file management

All the main frameworks listed above support rolling files but I think they leave the cleanup to you.

e.g. in the past I've used a scheduled Windows job that uses robocopy with with "/mov /minage X" to move old files elsewhere, then delete or whatever.

The EventSchemaTraceListener used in System.Diagnostics, which I blogged about recently, has a LimitedCircularFiles option, but not much tool support for viewing the logs (they are in XML).

2) Ability to send emails on certain types of messages logged (errors for example)

All the main frameworks listed above support this either directly or through extensions (additional listeners).

3) Ability to write messages to the windows event log

Again, all of the main frameworks support this, however I generally would recommend that writing to the Windows event log should be done directly and not via tracing.

One of the issues is what you asked about for automatic creation of sources.

Any writing to the event log (that goes through EventLog.WriteEvent) will automatically attempt to create the source on the first log message if it doesn't exist -- the problem is with security, only administrators are allowed to create sources, so running as a normal user this fails.

Because of this you really do need to add an EventLogInstaller, so that the source is created at install time (installation is done by administrator). Once created, any process can then write to the source.

This then leads to my recommendation that you need to create and write to the event log in code in order to ensure the event log source is the same. Also, if writing to the event log generally you don't want to be able to 'turn it off' through misconfiguration.

My personal recommendation is for the out of the box .NET Framework System.Diagnostics, in particular the Service Trace Viewer is excellent for diagnosing issues, particular in multi-tier, multi-threaded environments if using WCF where it can pass correlation identifies across tiers.

You can create your own logging lib... I did.

Take a look at PostSharp http://www.sharpcrafters.com/ they have very good examples of some basic logging systems.

http://alexworx.github.io/ALox-Logging-Library/

is a pretty straight forward library which is great if you have high demands on performance.