Develop Reference

How to correctly Dispose a class deriving from FileAppender in log4net [duplicate]

I have a class to whose every instance i create a new logger and attache a buffer appender and a flie appender to it. Everything is being done runtime and no information is picked from the config file.
Now to release resources at the class's custom dispose method i need to shutdown that specific logger and release all of its attached resources so as to avoid any memory leak.
At the moment what i have been doing is atleast flush the file appender and write all logging information but that neither releases the lock on that specific logging file nor does it release any of its resources.
What is the proper way of shutting down the logger while not shutting down other active loggers that are in process
log4net.ILog log = log4net.LogManager.GetLogger(loggerName);
foreach (IAppender iapp in log.Logger.Repository.GetAppenders())
{
BufferingAppenderSkeleton buffered = iapp as BufferingAppenderSkeleton;
if (buffered is BufferingForwardingAppender)
{
((BufferingForwardingAppender)buffered).Flush();
}
}
log.Logger.Repository.Shutdown();
I hope i have made my question clear enough :)

This worked for me:
log.Logger.Repository.Shutdown();
or you can take the long route:
foreach (log4net.Appender.IAppender app in log.Logger.Repository.GetAppenders()) {
app.Close();
}

In this instance, as you are not sharing any appenders, you should be able to use the IAppender.Close() method on all the appenders attached to your logger (this will also cause them all to be flushed).
You should cast the logger to IAppenderAttachable and get the appenders form there; this will allow you to make sure you only call Close() on the top level of your nested appenders. This should cause them to flush and close down their own children in the correct order.
http://logging.apache.org/log4net/release/sdk/html/M_log4net_Appender_IAppender_Close.htm
This will be very dangerous if you are using a standard log4net setup with a configuration!

Serilog Not Outputting Anything

Using .Net 4.6 I have a static Serilog helper class - I've stripped down to the essentials as follows:
public static class SerilogHelper
{
private static ILogger log;
private static ILogger CreateLogger()
{
if (log == null)
{
string levelString = SSOSettingsFileManager.SSOSettingsFileReader.ReadString(
"BizTalk.Common", "serilog.minimum-level");
SerilogLevel level = (SerilogLevel)Enum.Parse(typeof(SerilogLevel), levelString);
string conString = SSOSettingsFileManager.SSOSettingsFileReader.ReadString(
"BizTalk.Common", "serilog.connection-string");
var levelSwitch = new LoggingLevelSwitch();
levelSwitch.MinimumLevel = (Serilog.Events.LogEventLevel)level;
log = new LoggerConfiguration()
.MinimumLevel.ControlledBy(levelSwitch)
.WriteTo.MSSqlServer(connectionString: conString, tableName: "Serilog", autoCreateSqlTable: true)
.WriteTo.RollingFile("log-{Date}.txt")
.CreateLogger();
}
return log;
}
public static void WriteString(string content)
{
var logger = CreateLogger();
logger.Information(content);
}
I have the following unit test:
[TestMethod]
public void UN_TestSerilog1()
{
Common.Components.Helpers.SerilogHelper.WriteString("Simple logging");
}
I've stepped through the debugger to be sure that the "level" variable is being set correctly - it's an enum named "Debug" with value of 1.
Although the Sql Server table is created ok, I don't see any rows inserted or any log txt file.
I've also tried calling logger.Error(content) but still no output.
I've used the same helper code previously on a different site / project and it worked ok.
Where did I go wrong this time?

Serilog.Sinks.MSSqlServer is a "periodic batching" sink and by default, it waits 5 seconds before sending the logs to the database. If your test ends before the sink had a chance to write the messages to the database, they are simply lost...
You need to make sure you dispose the logger before your test runner ends, to force the sink to flush the logs to the database at that point. See Lifecycle of Loggers.
((IDisposable) logger).Dispose();
Of course, if you are sharing a static log instance across multiple tests, you can't just dispose the logger inside of a single test as that would mean the next test that runs won't have a logger to write to... In that case, you should look at your testing framework support for executing code once, before the test suite run starts, and once again, for when the a test suite run ends.
I'm guessing you are using MSTest (because of the TestMethod), so you probably want to look into AssemblyInitialize and AssemblyCleanup, which would give you the opportunity to initialize the logger for all tests, and clean up after all tests finished running...
You might be interested in other ideas for troubleshooting Serilog issues: Serilog MSSQL Sink doesn't write logs to database

LogManager.GetLogger and xmlconfigurator.configure sequence

I have custom xml file with the log4net configurations. Below code is used for configuring the log4net. It is working fine.
The question is how does LogManager.Getlogger gets the "MyLogger" when it doesnt know the config file details?
Should we maintain any sequence while calling LogManager.GetLogger and xmlconfigurator.configure ?
Class LoggerClass
{
private static readonly ILog fileLogger = LogManager.GetLogger("MyLogger");
public LoggerClass()
{
FileInfo logConfiguration = new FileInfo("ConfigFile.xml");
//Loading the configuration from the xml file.
XmlConfigurator.Configure(logConfiguration);
}
public void Log(string msg)
{
fileLogger.Log(......);
}
}

LogManager class has static methods that are used by a client to request a logger instance. The GetLogger method is used to retrieve a logger.
The GetLogger method return the object of type ILog which contains methods for logging at different levels and also has properties for determining if those logging levels are enabled in the current configuration.
And about the sequence, the invocation of the Xmlconfigurator.Configure() method sets up the logging functionality, hence before writing any log, the log4net library must be set up using this command Xmlconfigurator.Configure().
And the sequence of calling LogManager.GetLogger() and Xmlconfigurator.Configure() does not matter. Just make sure that before any logging, you have initialized the logger using LogManager.GetLogger() method and have set up the logger using Xmlconfigurator.Configure().
Reference: log4net documentaion
I hope, this helps and answers your question :)

Usually XmlConfigurator.configure() is done at application start in global.asax in ASP.NET application, so that all classes in application get log4net configurations.
//Global.asax
void Application_Start(object sender, EventArgs e)
{
log4net.Config.XmlConfigurator.Configure();
}

Exception capturing and Error logging

I have got a utility class, called ErrorLog, which basically does some basic error logging kinda stuff, recording error messages, stacktraces, etc.
So in my main c# app, I almost always chuck this piece of code, ErrorLog el = new ErrorLog() into the catch(Exception e) part, and then start calling its methods to do logging.
For example, here is 1 of the methods in ErrorLog class
public void logErrorTraceToFile(string fname, string errorMsg, string errorStackTrace)
{
//code here
}
Anyway, I am just wondering if it's a good approach to log errors in this way? It seems to me that this solution is a bit clumsy. (considering in each catch block you create el object and call its method, repeatedly.)
Also, in terms of storing error log files, where it the best / most reasonable location to save them? Currently, I just hard-coded the directory, C:\ErrorLogs\, as I am still testing a few things. But I do want to get it right before I forget.
So any ideas or suggestions?
Thanks.

Look at ELMAH This is very efficient in handling and catching errors in the application.
The errors get logged in the database.

Usually I'm using the Singleton pattern to have one application wide Logger.
public class Logger
{
protected static Logger _logger;
protected Logger()
{
// init
}
public void Log(string message)
{
// log
}
public static Logger GetLogger()
{
return _logger ?? _logger = new Logger();
}
}
As a place to store data I would use the application data or user data directory, only there you can be sure to have write access.
Edit: That's how you would use the Logger from any place in your code:
Logger.GetLogger().Log("test");

Multiple threads accessing singleton object in VS2010

I'm using Visual Studio 2010 to write a simple C#/.NET GUI app, wherein I use a Logger class to write tracing/debugging info to a single file from within all of the various classes of the project. (See source code below.)
Each class's constructor writes an entry to the log when one of its object types is instantiated. One of those classes is a custom GUI controller component (class FileAttributesCtl), which is contained in a couple of the GUI forms used by the program.
The problem I'm having is that two logfiles are created, about 200 msec apart. The first logfile contains (only) a message that a FileAttributesCtl object has been constructed, and the second contains all of the other messages written to the (supposedly) shared logfile output stream. So every time I execute my project code, I get two logfiles.
Stranger still, every time I rebuild my project (F6), a logfile is created for the FileAttributesCtl object, indicating that an control object of this type is actually instantiated during the build process.
This apparently has something to do with threading. If the logfile is not named uniquely (i.e., if I do not append a unique date/time string to the filename), I get an exception, indicating that more than one process (which is actually the VS2010 process itself) is currently using the file.
So my question is: How do I get the singleton object to actually be a single object?
A secondary question is: Why is VS2010 acting this way?
//----------------------------------------
// Logger.cs
class Logger
{
// Singleton object
private static Logger s_logger =
new Logger("C:/Temp/foo.log");
public static Logger Log
{
get { return s_logger; }
}
private TextWriter m_out;
private Logger(string fname)
{
// Add a date/time suffix to the filename
fname = ...;
// Open/create the logging output file
m_out = new StreamWriter(
new FileStream(fname, FileMode.Create, FileAccess.Write,
FileShare.Read));
m_out.WriteLine(DateTime.Now.ToString(
"'$ 'yyyy-MM-dd' 'HH:mm:ss.fff"));
}
...
}
//----------------------------------------
// FileAttributesCtl.cs
public partial class FileAttributesCtl: UserControl
{
private Logger m_log = Logger.Log;
public FileAttributesCtl()
{
m_log.WriteLine("FileAttributesCtl()"); //Written to first logfile
InitializeComponent();
}
...
}
//----------------------------------------
// FileCopyForm.cs
public partial class FileCopyForm: Form
{
private Logger m_log = Logger.Log;
public FileCopyForm()
{
// Setup
m_log.WriteLine("FileCopyForm()"); //Written to second logfile
// Initialize the GUI form
m_log.WriteLine("FileCopyGui.InitializeComponent()");
InitializeComponent();
...
}
...
}
Note: This is very similar to a question from Dec 2009:
Access to singleton object from another thread
but it does not have the answers to my question.
Update
Further investigation shows that the VS2010 is indeed instantiating the custom component during the build, probably so that it can render it in the Designer window.
Also, there are indeed two separate threads calling the Logger constructor (each having a different ManagedThreadID).
Using a static class initializer to construct the singleton object does not work; I still get two logfiles.
Resolution
Upon closer examination, I notice that the custom control is getting instantiated twice, and this is being shown in both logfiles.
Therefore I think the problem is entirely due to the fact that VS instantiates the custom control object prior to executing the program that results in the first logfile being created. The second logfile is then created after the program starts normal execution.
Thus the first logfile is simply a side effect of the build process, and does not really have anything to do with multiple threads executing during normal program operation.
The obvious solution is to remove all logfile side-effect code from the component constructors. Or simply just ignore the first logfile altogether.

It could very well be that Visual Studio is building your UI component (to display in the designer) and in the process, your constructor is getting called which is why you're seeing that log file during the build process.

Static data + threads = trouble
You need to synchronize access to the singleton (and initialization of the singleton).
A static constructor may help
class Logger
{
private static Logger
static Logger()
{
s_logger = new Logger("C:/Temp/foo.log");
}
// ...
or better yet use a logging library (log4net) that handles all this stuff for you.
As for VS builds causing a log to be created, I'm not surprised. It is probably instantiating the forms to discover information about your forms via reflection.
update per comments
#LoadMaster "The static class initializer does not
work. I added more info to the logfile
output to include the current thread's
ManagedThreadID, and sure enough,
there are two different thread IDs
creating the two logfiles."
That's strange. Per MSDN
The static constructor for a class
executes at most once in a given
application domain. The execution of a
static constructor is triggered by the
first of the following events to occur
within an application domain:
An instance of the class is created.
Any of the static members of the class
are referenced.
Your thread must have moved AppDomains or there is some code missing from your snippets.