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.
