First, we need to make sure that our project has a settings file. It is usually under the Properties node of the project. If it is not, right click on the solution and Add | New Item… | Visual C# Items | General | Settings File and name it Settings.settings. Next, drag it and drop it in your project’s Properties folder.

Next, you need to add a bool User setting called UpgradeRequired and default it to true. Next, at the very beginning of your Main, you check if UpgradeRequired is true, and if it is, upgrade the settings, set UpgradeRequired to false and save out the settings. This will pull in the settings from previous versions of your application.

Your settings should look like this,

The code should look like this,

static void Main( string[] args )
{
   // Upgrade settings if required
   if ( Properties.Settings.Default.UpgradeRequired )
   {
      Properties.Settings.Default.Upgrade();
      Properties.Settings.Default.UpgradeRequired = false;
      Properties.Settings.Default.Save();
   }

   // Do work...

   // At the end of main, save out any changes to settings
   Properties.Settings.Default.Save();
}

Now you just need to create new settings and use them in your application. Any setting with Application scope will be set in your app.config and will be read-only. This is often used for connection strings and other information that is unlikely to change. User scoped settings also have their default values in app.config, but any changes are written out to an XML file in the user’s AppData folder.

Also, notice that code gets generated for any setting that you create and you access it through a property on Properties.Settings.Default. You can use any complex type for a setting, including classes in your application, as long as they are Serializable.

As I started to use that updated version, I soon discovered that the current source has many bugs and actually fails many of its own test suites. I tried to get the test suites running and submitted more patches for those, but still the project remains dormant. Without the support of at least one member of the team, it is difficult to revive a project without forking it, which I don’t want to do.

I ended up talking with a member of the NHibernate team, I learned that they were also moving away from log4net and were looking at NLog, the new player in .NET logging. I read through the website, followed the forums and liked what I saw, so I decided to move over to NLog.

Switching over actually turned out to be fairly straight-forward once I managed a few regular expressions for search and replace. Roughly, I performed the following steps,

1. I did a search and replace using Notepad++ in all of my project files to switch the references over.
2. I then replaced all of my using statements.
3. Next came the log instantiation. log4net uses ILog where NLog uses Logger. In log4net you also tend to use GetLogger( typeof( MyClass ) ) where in NLog you just use GetCurrentClassLogger(). This required a bit of RegEx magic.
4. The hardest step was finding every instance of log.Warn( msg, exception) and converting them to log.WarnException( msg, Exception ). I did this nearly manually for each of the log levels, inspecting to see where I was passing in exceptions.
5. Then for each of the log levels, I converted instances of log.WarnFormat( "Substitute this {0}", val ) to log.Warn( "Substitute this {0}", val ). This was another easy file replacement.
6. Lastly, I removed my XmlConfigurator attributes and changed my log configurations. A quick recompile, a few minor fixes and I was up and running. Painless!

So far, I don’t regret my choice at all. I find the configuration of NLog to be much more intuitive and the Intellisense for the config file in Visual Studio sure helps. The documentation is still a bit sparse in places, but it is getting better. I do worry because it is currently a one man show, but it Jaroslaw Kowalski does seem fairly active and committed. Time will tell…

Earlier this week, we moved one of our projects over to .NET 4.0 and once again logging failed. In the console window while debugging the app, I noticed the following,

log4net.Util.TypeConverters.ConversionNotSupportedException: Cannot convert from type [System.String]
  value [127.0.0.2] to type [System.Net.IPAddress] --->
  System.Net.Sockets.SocketException: No such host is known
       at System.Net.Dns.InternalGetHostByAddress(IPAddress address, Boolean includeIPv6)
       at System.Net.Dns.GetHostEntry(String hostNameOrAddress)
       at log4net.Util.TypeConverters.IPAddressConverter.ConvertFrom(Object source)

So, I tried changing back to localhost and the error changed to,

log4net:ERROR [UdpAppender] Unable to send logging event to remote host ::1 on port 7071.
      System.Net.Sockets.SocketException (0x80004005): An address incompatible with
      the requested protocol was used
       at System.Net.Sockets.Socket.SendTo(Byte[] buffer, Int32 offset, Int32 size, SocketFlags
         socketFlags, EndPoint remoteEP)
       at System.Net.Sockets.UdpClient.Send(Byte[] dgram, Int32 bytes, IPEndPoint endPoint)
       at log4net.Appender.UdpAppender.Append(LoggingEvent loggingEvent)

At this point, I have some clues, specifically that localhost was being resolved as the IPv6 address ::1, not the IPv4 address 127.0.0.1. Looking through the reported issues I found that this problem had been reported and fixed in 2007. Unfortunately, that code isn’t in the release, so I downloaded the latest source and recompiled log4net. Of course, they don’t release the signing key, so I generated my own and signed the assembly myself.

This fixed my problems with the UdpAppender, although, if you use localhost on a Windows Vista or Windows 7 machine, it will resolve to the IPv6 address, so make sure that your receiver is listening on the IPv6 address. For example, in log2console, under Receivers, set Use IPv6 Addresses to true for the UDP receiver. If your receiver does not support IPv6, use 127.0.0.2 for the address.

To save other people the hassle of recompiling log4net themselves to get the latest fixes, I have uploaded a release version of the assembly. Download it here.

• log4net 1.2.10.1 -  260 KB Zip

We are using this version of the assembly in our own projects, but I make no guarantees as to its stability.

Update: Just to  be clear, this is not an official log4net release and it is only compiled against .NET 2.0. I have made no code changes, it is just the code that is currently in the repository. This is only intended to save you having to download and compile if you run into the same problems I did. It is also not extensively tested. We are using it and File, Rolling File, Event Log and UDP Appenders seem to be working fine.

Update 2: Since I have released this, I have found several bugs in the current source. For example, setting Append=true to a File or Rolling File causes every log message to truncate the file! Because of that I would recommend that you don’t download this unless you really need it. I have finally given up on log4net and converted all of my projects over to NLog.

Copier<ICustomer>.Copy( customer ).To<ICustomerView>( view );

Today, I am going to use extension methods to simplify the above code even further. I want to be able to write

customer.CopyTo<ICustomerView>( view );

or if we want to rely on type inferencing with the generic CopyTo method, you could write it as simply as

customer.CopyTo( view );

How is this done? Using extension methods, it was actually much simpler than yesterday’s Copier class. In fact, it just ended up being one line of code for the CopyTo method and for the CopyFrom method. I simply wrapped the CopyHelper class like this.

public static class CopierExtensions
{
    public static void CopyTo<T>( this object from, T to ) where T : class
    {
        CopyHelper.Copy( from.GetType(), from, typeof( T ), to );
    }

    public static void CopyFrom<T>( this object to, T from ) where T : class
    {
        CopyHelper.Copy( typeof( T ), from, to.GetType(), to );
    }
}

The only problem I have with this is that the class that the extension methods are applied to are not constrained by an interface, so all matching properties are copied. Does anyone have any ideas on that?

I have uploaded a copy of the solution for this project along with an NUnit test project. Take a look, use it if you like and feel free to give me suggestions for improvements.

In the next few posts I was thinking of extending these classes even further. I might add attributes that allow you to ignore certain properties, maybe add an attribute that specifies interfaces that you are allowed to copy to, possibly an attribute that allows properties to automatically be converted between types. What would you find useful or like to see? Would you like to see a post on the performance using these methods?

// Copy the data from the customer to the view
view.Address = customer.Address;
view.Country = customer.Country;
view.FirstName = customer.FirstName;
view.LastName = customer.LastName;
view.PostalCode = customer.PostalCode;
view.Province = customer.Province;

The newly created CopyHelper class allows me to shorten that to this.

// Copy the data from the customer to the view (using reflection in .NET 1.x)
CopyHelper.Copy( typeof(ICustomer), customer, typeof(ICustomerView), view );

Today, I want to extend that code using Generics and a fluent interface so that I can write code like this.

// Copy the data from the customer to the view (using reflection and generics in .NET 2.0)
Copier<ICustomer>.Copy( customer ).To<ICustomerView>( view );

Internally, I use my CopyHelper class from my last post. I extend that by creating a generic Copier class. I make the constructor private so that it can only be created as a part of the fluent interface, in this case the static copy method. Using the instance of the Copier class that was returned from that method, you can then copy To or From another class instance.

Here is the code.

public sealed class Copier<T1> where T1 : class
{
    #region Private Members

    private readonly T1 _subject;

    #endregion

    #region Public Interface

    /// <summary>
    /// Begin the copying process.
    /// </summary>
    /// <param name="interface1">The object you are copying from or to</param>
    /// <returns>An instance of the Copier class so that you can
    /// continue with the copy to/from in a fluent interface.</returns>
    public static Copier<T1> Copy( T1 interface1 )
    {
        return new Copier<T1>( interface1 );
    }

    #endregion

    #region Construction

    /// <summary>
    /// Private constructor so that it can only be created as a part of a fluent interface.
    /// </summary>
    /// <param name="subject"></param>
    private Copier( T1 subject )
    {
        _subject = subject;
    }

    #endregion

    #region Copier Methods

    /// <summary>
    /// Copies properties from the subject to the passed in object.
    /// </summary>
    /// <typeparam name="T2">The type of object you are copying into.</typeparam>
    /// <param name="to">The object to copy into.</param>
    /// <returns>The modified object that you passed in.</returns>
    public T2 To<T2>( T2 to ) where T2 : class
    {
        CopyHelper.Copy( typeof( T1 ), _subject, typeof( T2 ), to );
        return to;
    }

    /// <summary>
    /// Copies properties from the passed in object into the subject.
    /// </summary>
    /// <typeparam name="T2">The type of object you are copying from.</typeparam>
    /// <param name="from">The object to copy from.</param>
    /// <returns>The modified subject that you originally passed in the Copy method.</returns>
    public T1 From<T2>( T2 from ) where T2 : class
    {
        CopyHelper.Copy( typeof( T2 ), from, typeof( T1 ), _subject );
        return _subject;
    }

    #endregion
}

I would like to constrain T1 and T2 to interfaces at compile time, but I am not sure if that can be done. If you have ideas, please post them in the comments. I thought of using reflection to check if T1 and T2 are interfaces at run time, but I am a big believer in favouring compile time errors over run time errors.

In my next post, I am going to use C# 3.0 extension methods to further simplify copying allowing you to write code like this.

// Copy the data from the customer to the view (using extension methods in C# 3.0)
customer.CopyTo<ICustomerView>( view );

I am very interested in hearing your feedback on this, so be sure to post to the comments. Do you think this is a good idea? Do you have suggestions for improvements? Let me know.