Choosing Logging Library for .Net : NLog

When it comes to logging, printing it out yourself to console or file probably the most straightforward way. However, if you want to get more structured in your log, with level and flexible on/of switching you'll need a more dedicated logging library. However, like any library, choosing the sweet spot where you get the feature you want but with the least complexity and learning curve can be challenging.

As for logging, when I research around the two that pop up most is log4net and NLog. The choise is pretty simple though, log4net is good but pretty outdated now while NLog is quite active, well-supported has rich feature. So, the choice goes to NLog.

Quick Usage :

After you link the library (using NuGet or manually). Declare the logger in your class :

private static Logger logger = LogManager.GetCurrentClassLogger();

and call at the place that needed it :

logger.Debug("log message");

You can add a lot of additional details to your log with its predefined variables. You can consult the manual to see what is available. Also, since you declare logger on each class, it can automatically  print in which class and the point where the log is called. It is quite useful for debugging.

Winforms C# : Prefer initialization in constructor instead of Form_Load event handler

On Windows Forms, I have been doing initialization of values on Form_Load event handler. I use constructor mostly for make instances of member variables and setting basic/default values. I did the rest of the settings e.g: config, last state, on Form_Load. It turns out that it's not actually a best practice to do so.

I've just stumbled upon this discussion on Stack Overflow that explain that it is actually better to minimize the use of Load. In summary, here's the guideline on Constructor vs. Load issues :

1. Initialize things on constructor 
2. Only use Load for code that needs valid windows handle e.g: code that requires the window size and location to be known
3. Override  OnLoad instead of using Form_Load event handler. This ensure more deterministic order of execution in relation to parents OnLoad call

I guess it's time to change the habit.

Use Fody to Simplify INotifyPropertyChanged Implementation

I was looking for a way to simplify implementing INotifyPropertyChanged. The standard way was too noisy to my taste so it would be really nice if there is a way to simplify it. Early on the search I stumble upon PostSharp . However, it's quite expensive and seems to be a relatively big "framework" for just my simple needs.

I later found the PropertyChanged.Fody and it fits my needs nicely. It is free and works really well. You just need to install with the command below in NuGet's Package Manager Console

PM> Install-Package PropertyChanged.Fody

and you are good to go. NuGet will take care of installing the needed dependencies e.g: Fody.  Implementing INotifyPropertyChanged is now just a matter of adding  [ImplementPropertyChanged] attribute to a class. Very convenient.