I'm designing a console application for the first time in my career. This console application is an engine which will do a task every night at particular time. I'm going to schedule this application using windows task scheduler.
Now I need to log every step in this task. I'm not sure what logger best suits for this kind of application. This log messages may be stored to a database, xml or a flat file.
Can you give your suggestions for best logger application for this kind of scenario?
Try NLog it is basically port of Log4j to .NET. You can configure it programmatically or through .xml file. The second option is handy because you don't have to recompile your project every time you want to change logging options. In code common use would look like.
class MyClass
{
private static readonly Logger Logger = LogManager.GetCurrentClassLogger();
public void MyMethod()
{
// available logging levels TRACE,INFO,DEBUG,WARN,ERROR, FATAL
Logger.Debug("Debug message");
}
}
We typically use log4net for all logging in the applications that I am currently part of maintaining. Works quite well. Then we have scripts that compresses the logs on a daily basis into zip files to save disk space (since some of the applications are quite verbose in their logging).
The most common logging frameworks on .NET are Log4Net and NLog, although there are others.
Related
I have a DLL which will be used from a non-.NET application, so it doesn't appear that it will read a config file.
I've read solutions where you can code custom solutions to explicitly read the config from a DLL, but I don't see how to get the logging component to read that.
The config page for logging in System.Diagnostics claims that you can set everything from code. I have found how to create and add a listener.
static LogFactory() {
TextWriterTraceListener myListener = new TextWriterTraceListener("C:\\Logs\\app.log", "myListener");
Trace.Listeners.Add(myListener);
myListener.WriteLine("Test message.");
Trace.WriteLine("Another test");
myListener.Flush();
}
The file is created but nothing gets written to it, either from this explicit write, or from any call to logging in the app.
TRACE is set in the build options.
It's not clear from your question how exactly is the DLL going to be used from the non-.NET application and how they are communicating with each other, but ideally the DLL would not have its own log... It would write to the log of the main app that is consuming it.
That means you would design your DLL in such a way that the consumer can provide you with a way to write to their logs (e.g. by passing an ILogger interface that are common/known by both DLL and host app, or at least a delegate of some kind e.g. Action<string>) through an agreed upon bootstrapping method that the host app would call as part of the bootstrapping of the app.
If you do decide to have a separate logging for the DLL without cooperation with the host app, then you could try using a ModuleInitializer which is a special function you can add to your .NET assembly that runs when the assembly is loaded for the first time.
As of this writing, an easy way to add ModuleInitializers to assemblies is through a Fody plugin called ModuleInit.
As for emitting the logs from within your DLL (regardless of the approach above), you might want to consider Serilog or NLog which offer a much more rich logging capabilities compared to Trace.
We have c# application with several different modules. We are using log4net for logging. What should be done to log the messages:
Create a centralized logging project: The application classes to use centralized logging project's dll's static methods to log the messages. So, no class in application creates the logger, all logging requirements to be fulfilled by this dll OR
All types in the application itself creating their own loggers: Easy to check which type generates which message, easy to manage different type of logging requirements i.e.we can throttle logging behavior of each type independently, like one class logging ALL logs but other only loggin ERROR.
What is the preferred practise?
The approach2 has its own benefit but approach1 looks clean as each class would no longer be responsible for calling "GetLogger(typeOf(className))".
What is the recommended way?
It really depends on the usecase, when making a library it can make sense to use method 1. However when making a complex program method 2 will help you to manage different logger independently. Method 2 will give the also the option to log all in you project like method 1 does. However method 1 does not support differing on logger. So method 2 seems a better choice in most cases.
I have a solution that is a combination of WCF, console applications, services, and ASMX projects. I need a way to have a single log4net config file for all of these projects. I cannot inject a logger into these classes. I'm thinking of a central log manager that wraps log4net.
What's a good way to provide a log manager that allows this?
Also, I also don't want to be reading the config file all the time. I'd rather load it up once the first time it's needed. Especially since this will mean reading it each time an ASMX page is loaded.
Thank you.
You can make a service, then all your projects can log to the service. You will only have one configuration and change all on configuration at one place.
I need to create a Error logging project from scratch in C#.
I would like to save to a file with several levels, this logging project I am taking as an assignment from which I can learn many things and want to build it as small loggin utility for now.
I saw few loggin project which has singleton pattern and a config file having some entries and also in the consuming application config - some references of logger proj interface are there
can some one please give me an idea as how can I create a new logger
proj from scratch and what is the purpose of having entries in
config ?
pseudo code for logger project or any link
Thanks in advance.
Instead of implementing your own logging mechanism you may want to check whether existing components are an option. For example log4net is a frequently used framework that people use for .NET based projects.
Also, the Logging Application Block from Microsoft:
http://msdn.microsoft.com/en-us/library/ff632023.aspx
http://msdn.microsoft.com/en-us/library/ff664569(v=PandP.50).aspx
There are several key elements you need to consider before making one from scratch. Just to name what comes to my head :
How do you want to log? Do you want to save logs to a file, in a database, to send mails, just to have the logs shown in a console?
If you persist the logs, do you want to log everything, forever, or you want a "rolling" X lines to be kept, the rest discarded?
Do you want to have several level of logs? For example, you could log some things Info, Warning, Error, Critical Error, etc.
Do you want your logging library to support custom formatting for the logs?
As for the question about the config, it's really something you want to do. If you're talking about the app.config files, it allows you to can change the configuration of your application without rebuilding it. It can also provide some default parameters the user can override. By user, I mean another developer using your library.
I am doing something unusual.
I have an application, it runs as a windows service.
what it does is that, it monitor one folder, when ever there is some new file put into that folder, the application will do something to the file.
Whenever there is an error when processing one file. I need to create a text file, and put the error/exception information into that text file. (later i can do something with this file)
so there is something like this
FileWatch, when there is a new file, do following :
try
{
processing file
}
catch(Exception ex)
{
MyLogger write exception message into one new text file
}
So far how i did it is that. I create a class for example MyLogger, whenever i new one MyLogger, it creates a text file (the name matters, need to be a specific format), and there is one method in side MyLogger "WriteError(string message)", it writes text into that file.
Since i used log4net in my application. Do you think i should modify my logger, to extend some class from log4net, so that i can get some benefit? (not sure what kind of benefit i will get, but log4net is a good logging framework, the way it handle text file might have thing that i do not aware)
Thanks
log4net or any other generic logger is helpful if
1) you want to have a consistent logging facility in many places across your application; and/or
2) you want the ability to customize logging format, level and so on.
From your description it sounds like there is a single point in your app where you need to log the exception in a specific way. If this is correct, you will probably gain no benefit from creating a custom logger - just write a method that logs exception to a file in the way you need.
If I misunderstood you, and there is a need for generic logger (that is, either 1) or 2) above is true), extending log4net by inheriting a logger or creating a wrapper is fine.
I've created log4net wrappers before. I find it handy to start this way as you don't always know what the logging requirements are at the start of a project. My rule has been that the log4net library can only be referenced from my own "logging" namespace. This way, the application code only calls the wrapper, and the wrapper is the only point of contact to the log4net functionality.
In the long run, it's probably worth investing in building your own logger. If you encapsulate log4net properly, you should be able to make this upgrade rather easily, without having to change your code.
Why not use Trace Listeners from the .NET framework? They provide many of the benefits of a logging network, without the need to incorporate an external framework.
Benefits include centralized log management and the ability to direct the output logs to one or more sources such as a console window, text file, or the Windows Event Log.
You should spend some time creating your own logger that does exactly what you want. This would be the best way. Is also fairly easy and you have full control on the customization so you can make the output look and feel as in log4net. You could Google for logging sample and start modifying that one.
I am not sure if I would use a log framework for this purpose. I have the impression that writing this text file in the exception case is part of your business process. Logging serves a different purpose that can be turned off without affecting business processes...