Thursday, January 17, 2013

Readable type name for generic types

I am working on a messaging subsystem capable of transmiting generic XML messages. A message could possibly be interpreted and deserialized to a concrete type and I try to find a readable and useful way of denoting a type name.

For a simple class like this one

namespace ClassLibrary1
{
    public class Class1
    {
    }
}

what would be the output of

var type = typeof(Class1);
 
Console.WriteLine( type.Name );
Console.WriteLine( type.FullName );
Console.WriteLine( type.AssemblyQualifiedName );

?

Well, the output is

Class1
ClassLibrary1.Class1
ClassLibrary1.Class1, ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKey Token=null

Which one of these would you pick as a public denotation of the type name? My obvious choice was the second one, what was yours?

I was however quite surprised to see that this one

namespace ClassLibrary1
{
    public class GenericClass<T>
    {
 
    }
}

with

var type = typeof(GenericClass<Class1>);
 
Console.WriteLine( type.Name );
Console.WriteLine( type.FullName );
Console.WriteLine( type.AssemblyQualifiedName );

doesn’t look as clean as I expected:

GenericClass`1
ClassLibrary1.GenericClass`1[[ClassLibrary1.Class1, ClassLibrary1, 
   Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]]
ClassLibrary1.GenericClass`1[[ClassLibrary1.Class1, ClassLibrary1, 
   Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], 
ClassLibrary1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

A small disaster I would say. The type itself is denoted nicely but the inner generic type is either not denoted at all (type.Name) or denoted with full information.

It seems that other people have extactly the same problem.

And, surprisingly, the simplest answer is to use .ToString().

var ct = typeof(Class1);
Console.WriteLine( ct.ToString() );
 
var gt = typeof( GenericClass<Class1> );
Console.WriteLine( gt.ToString() );

gives

ClassLibrary1.Class1
ClassLibrary1.GenericClass`1[ClassLibrary1.Class1]
which is exactly what I expect. I hope this is reliable.

Wednesday, January 16, 2013

Custom ConfigurationManager provider

The ConfigurationManager facade class is a solid member of the base class library. It allows one to access the application settings, connection strings and other configuration sections from configuration files.

The problem with the facade class is that its members are static and there doesn’t seem to be an easy way to mock the internal implementation. Thus, testing becomes complicated as the internal implementation is bound to the *.config files.

A natural way to resolve this difficulty is to provide another facade but this time a mockable one. You start with an interface :

public interface IConfigurationManager
{
    NameValueCollection AppSettings
    {
        get;
    }
 
    ConnectionStringSettingsCollection ConnectionStrings
    {
        get;
    }
 
    object GetSection( string sectionName );
}

and then you let it be injected into the facade

/// <summary>
/// Gateway/facade dla klienta
/// </summary>
public class ConfigurationManagerGateway
{
    private static IConfigurationManager _provider = 
       new DefaultConfigurationManager();
 
    public static void SetConfigurationProvider( 
        Func<IConfigurationManager> configurationProvider )
    {
        _provider = configurationProvider();
    }
 
    public static NameValueCollection AppSettings
    {
        get
        {
            return _provider.AppSettings;
        }
    }
 
    public static System.Configuration.ConnectionStringSettingsCollection ConnectionStrings
    {
        get
        {
            return _provider.ConnectionStrings;
        }
    }
 
    public static object GetSection( string sectionName )
    {
        return _provider.GetSection( sectionName );
    }
}
 

where the default implementation points back to the old facade

public class DefaultConfigurationManager : 
   IConfigurationManager
{
    #region IConfigurationManager Members
 
    public System.Collections.Specialized.NameValueCollection AppSettings
    {
        get 
        {
            return ConfigurationManager.AppSettings;
        }
    }
 
    public System.Configuration.ConnectionStringSettingsCollection ConnectionStrings
    {
        get 
        {
            return ConfigurationManager.ConnectionStrings;
        }
    }
 
    public object GetSection( string sectionName )
    {
        return ConfigurationManager.GetSection( sectionName );
    }
 
    #endregion
}

This approach lets you provide any implementation and inject it into the new facade. And this is the major drawback of this approach – it forces the client code to switch to the new facade or at least to the new interface. For a large code base this means that a lot of code which uses the old facade must be inspected and manually switched to the new facade.

But, hey, this is not a big issue – you could think – I do it once and at least from the very moment I have a correct architecture of the system.

Alas, there is just another minor drawback. The new interface is a custom interface which means that it has to be provided in a custom class library. Suppose then you have two large code bases, X and Y, developed independently. The X code base solves the configuration manager problem by providing the new interface and the new facade. The Y code base solves the same problem by providing its own, yet another interface with yet another facade.

And then, you try to merge X and Y in the new composite solution, Z. For this, you need two different implementations of injected configuration providers (or better, a implementation and one adapter so that the actual implementation is provided only once).

All these major and minor issues made me rethink the issue once again. I started to find a way to inject a custom implementation of the configuration provider into the existing facade, the ConfigurationManager class. And, surprisingly, there is a way.

You see, if you decompile the ConfigurationManager facade, it turns out that internally all it does it is uses an internal provider of type System.Configuration.Internal.IInternalConfigSystem (in fact, in contrary to its name, the interface is not internal!). And the facade has an explicit method to inject this provider, ConfigurationManager.SetConfigurationSystem! The only subtle issue is that the injection method is, for an unknown reason, internal.

All this means that the architecture of the existing facade is prepared for an injectable provider but for some unknown reason someone has blocked the explicit possibility to inject a provider.

And of course, this is not a real issue if you have the reflection.

What you need then is to have a way to inject your own implementation somewhere early in the app lifecycle (the composition root perhaps). With a help of a concrete implementation, all you have to do is to provide actual settings:

public static class ConfigurationManagerConfigurator
{
    public static void SetConfigurationSystem( IInternalConfigSystem configSystem )
    {
        Type configurationManagerType = typeof( ConfigurationManager );
 
        // this does the magic. calls the internal method
        // which allows me to inject a provider
        // why, oh why this is not public?        
        configurationManagerType.InvokeMember( 
            "SetConfigurationSystem", 
              System.Reflection.BindingFlags.InvokeMethod | 
              System.Reflection.BindingFlags.Static | 
              System.Reflection.BindingFlags.NonPublic, 
        null, 
        configurationManagerType, new object[] { configSystem, true } );
    }
}
 
public class DynamicConfigSystem : 
   System.Configuration.Internal.IInternalConfigSystem
{
    private NameValueCollection appSettings;
    private ConnectionStringSettingsCollection connectionStrings;
    private Dictionary<string, object> sections;
 
    #region IInternalConfigSystem Members
 
    public DynamicConfigSystem( 
            NameValueCollection AppSettings,
            ConnectionStringSettingsCollection ConnectionStrings,
            Dictionary<string, object> Sections )
    {
        this.appSettings = 
            AppSettings != null ? 
            AppSettings : new NameValueCollection();
        this.connectionStrings = 
            ConnectionStrings != null ? 
            ConnectionStrings : new ConnectionStringSettingsCollection();
        this.sections = 
            Sections != null ? Sections : new Dictionary<string, object>();
    }
 
    public object GetSection( string sectionName )
    {
        if ( sectionName == "appSettings" )
            return this.appSettings;
        if ( sectionName == "connectionStrings" )
            return this.connectionStrings;
 
        if ( this.sections.ContainsKey( sectionName ) )
            return this.sections[sectionName];
        else
            throw new ArgumentException( "Undefined configuration section" );
    }
 
    public void RefreshConfig( string sectionName )
    {
    }
 
    public bool SupportsUserConfig
    {
        get 
        { 
            return true; 
        }
    }
 
    #endregion
}

Now I can have my custom configuration injected and there is no need to rewrite the existing code:

// create the configuration in memory
NameValueCollection appSettings = new NameValueCollection();
appSettings.Add( "foo", "bar" );
 
// inject the custom provider
ConfigurationManagerConfigurator.SetConfigurationSystem( 
   new DynamicConfigSystem( appSettings, null, null ) );
 
// prints "bar" - configuration is server by the built-in facade
Console.WriteLine( ConfigurationManager.AppSettings["foo"] );
My only hope is that rather than changing the internal implementation, BCL engineers will make the provider injection available for everyone.