My virtual static implementation

What I want is to be able to write code like this:

public T Create<T>() where T : new(string)

{

    return new T("something");

}

or this:

public interface IConverter<Tin, Tout>

{

    static Tout Convert(Tin value);

}

 

public static Tout Convert<TConverter, Tin, Tout>(Tin value)

    where TConverter : IConverter<Tin, Tout>

{

    return TConverter.Convert(value);

}

but current (4.0) version of C#/CLR doesn’t allow me to do it, so I was forced to think about substitute solution.

If we think about virtual methods we need class that has them and we need instance of this class.

public class IntStringConverter : IConverter<int, string>

{

    public static readonly IntStringConverter Instance = new IntStringConverter();

    public virtual string Convert(int value)

    {

        return value.ToString();

    }

}

But this gives us nothing because we need to know exact type. So I’ve created following class

public static class Static<T> where T : new()

{

    private static bool initilized;

    private static T value;

 

    public static T Value

    {

        get

        {

            if (!initilized)

            {

                value = new T();

                initilized = true;

            }

            return value;

        }

    }

}

to use it instead of Instance field.

And now I can write Convert method like this:

public static Tout Convert<TConverter, Tin, Tout>(Tin value)

    where TConverter : IConverter<Tin, Tout>, new()

{

    return Static<TConverter>.Value.Convert(value);

}

or Create method

public interface INew<T, T1>

{

    T New(T1 param1);

}

 

public static T Create<T, TFactory>() where TFactory : INew<T, string>, new()

{

    return Static<TFactory>.Value.New("something");

}

So my solution is to create one instance of my “virtual static” type and make sure all other classes can use it without tight coupling to some static field. Right now, all they need to know is Static<T> class.

Why should you use generics instead of simple interfaces in method parameters in .NET

Answer: for performance reasons

Consider following methods

public static void TestMax()

{

    int max = (int)Max(5, 10);

}

 

public static object Max(IComparable left, IComparable right)

{

    return left.CompareTo(right) > 0 ? left : right;

}

Now let see how TestMax() is looking when compiled to IL

.method public hidebysig static void TestMax() cil managed
{
    .maxstack 2
    .locals init ([0] int32 max)
    L_0000: nop 
    L_0001: ldc.i4.5 
    L_0002: box int32
    L_0007: ldc.i4.s 10
    L_0009: box int32
    L_000e: call object Test.Program::Max(class [mscorlib]System.IComparable, class [mscorlib]System.IComparable)
    L_0013: unbox.any int32
    L_0018: stloc.0 
    L_0019: ret 
}

So as we can see for this simple call we have two box instructions. This means that we have two heap allocations (malloc() in c).


Now lets see how generic version will behave:

public static void TestMax()

{

    int max = Max(5, 10);

}

 

public static T Max<T>(T left, T right) where T : IComparable

{

    return left.CompareTo(right) > 0 ? left : right;

}

and TestMax() in IL looks like this:

.method public hidebysig static void TestMax() cil managed
{
    .maxstack 2
    .locals init (
        [0] int32 max)
    L_0000: nop 
    L_0001: ldc.i4.5 
    L_0002: ldc.i4.s 10
    L_0004: call !!0 Test.Program::Max<int32>(!!0, !!0)
    L_0009: stloc.0 
    L_000a: ret 
}

As you can see instead of box we now have ldc instructions which means that now we are allocating 2*4 bytes on the stack which is much much faster then allocation on the heap.

So the long answer is: Because by this simple tweak you can speed up your method for all struct parameters.

How to test generic class/methods with Rhino mocks

Rhino mocks is my isolation framework of choice and as you my notice from my earlier post I use generics as my Inversion of Control tool. Problem is that when you use Rhino Mocks you cannot mock constructor (right now to my knowledge only TypeMock Isolator can do this). The reason for this is that Rhino Mocks generates mocks at runtime, and for testing methods that use new() constraint you need to know the mock type at compile time.
So the only way to solve this seems to be creation of mock classes by hand. But then shortly I realized that all of them seems to look very similar.
So…

Here is how I solved this:
First I created t4 file called Mocks.tt which I attach to my test project.

It’s almost unreadable, so don’t be scared – I’m not t4 expert, it’s my first experiment :-)

This file is:

• generating MockAttribute class
• searching for each class in project (it belongs to) that have such attribute and are partial and then creates mock methods for each interface this class implements and for default constructor.

To create such mock type I must first write something like this:

[Mock]

public partial class MockAskEmailWindow : IQuestion

{

}

Then click “Run Custom Tool”

And because IQuestion is defined like this

public interface IQuestion

{

    string Ask(string question);

}

in file generated by t4 script I have following code

public partial class MockAskEmailWindow

{

    private readonly MockAskEmailWindow mock;

    public bool Created;

    public MockAskEmailWindow Object;

 

    public MockAskEmailWindow()

    {

        if (Service<Queue<MockAskEmailWindow>>.Value != null)

        {

            mock = Service<Queue<MockAskEmailWindow>>.Value.Dequeue();

            mock.Created = true;

            mock.Object = this;

        }

    }

    public virtual string Ask( string question)

    {

        return mock.Ask( question);

    }

}

Now if we have following method to test:

public string AskForNewUserEmail<TQuestion>() where TQuestion : IQuestion, new()

{

    throw new NotSupportedException();

}

We write test like this:

[Test]

public void ShowUsermNewUserEmailRequestAndRetrieveEmail()

{

 

    var ask = MockRepository.GenerateMock<MockAskEmailWindow>();

 

    ask.Expect(a => a.Ask("Plase type email of the user you want to create")).Return("test@test.pl");

 

    using (Service.CreateQueue(ask))

        Assert.AreEqual("test@test.pl", AskForNewUserEmail<MockAskEmailWindow>());

    ask.VerifyAllExpectations();

}

And to make test pass we change our method to

public string AskForNewUserEmail<TQuestion>() where TQuestion : IQuestion, new()

{

    return new TQuestion().Ask("Plase type email of the user you want to create");

}

Seems, simple :-)
The only unknown class that I used here is Service<> so here is it’s very simple code

public class Service<T> : IDisposable where T : class

{

    private readonly T parent;

    [ThreadStatic] private static T current;

 

    public Service(T service)

    {

        parent = Value;

        Value = service;

    }

 

    public static T Value

    {

        get { return current;}

        private set {current = value;}

    }

 

    public void Dispose()

    {

        Value = parent;

    }

}

 

public static class Service

{

    public static Service<Queue<T>> CreateQueue<T>(T value, params T[] values)

    {

        var queue = new Queue<T>(values.Length + 1);

        queue.Enqueue(value);

        foreach (var v in values)

            queue.Enqueue(v);

        return new Service<Queue<T>>(queue);

    }

}

This class I created as my implementation of service locator earlier when I tried use this pattern to decouple the code. As you can see from code, service implementations can be nested and are specific for current thread (I failed to create services that work between multiple thread because of strange CallContext class behaviour when someone called EndInvoke()). If anyone is interested here is example of usage:

using (new Service<IQuestion>(new MockAskEmailWindow()))

{

    //some code

    using (new Service<IQuestion>(new MockAskEmailWindow()))

    {

        //some other code that uses other version of IQuestion

        //by calling Service<IQuestion>.Value

    }

    //here we use again the first IQuestion

}

But back to generic method testing as you can see from example above the scheme is following:

• Create mocks using Rhino Mocks
• put them in the service queue
• run tested method
• When mocked type instance is created it takes mock from service queue
• All calls to newly created object are redirected to mock created in test

And that’s it.

Just one more note: Because of EnvDTE unavailability to read generic constraints (and because it was failing when I called CodeMethod.StartPoint and CodeMethod.EndPoint) I was unable to mock such methods. I solved this by don’t mocking it at all. You must implement such method in your part of partial mock class.

Hope this helps someone

C# generics – free but ugly Dependency Injection

I must admit that: I’m obsessed with generics for some time.

 

Some time ago my way to decouple code was to use IServiceProvider. It was great but required from me and my coworkers to pass it to each newly created class.

In the mean time other developers used different IoC containers which solved this problem by using static methods to register and use specific objects. For example:

IOC.Register<ISomething>(new Something());

 

And later in the code it was used like this:

 

IOC.Resolve<ISomething>().DoSomething();

As I said it solved one problem but I had still other problems with that:

• Because of static methods I can have only one configuration for the whole application
• Even if I tried to create my version of IoC container that can be nested like this
  

  using(new Service<IService>(new ServiceImplementation()))

  {

      //some code

      //and later

      using(new Service<IService>(new AnotherServiceImplementation()))

      {

          //some other code

      }

  }

  
  I failed to create a version that worked correctly between multiple threads, because I was forced to use static fields and I was unable to force CallContext to not overwrite current Thread configuration when EndInvoke() was called.
• If I want to write component that may be used by someone else the only way to inform him about required dependencies is documentation, or runtime errors.
• I must agree with Joel Spolsky that code that uses IoC containers is less readable

Aside from above I’m using static language C#. Why should my dependencies be resolved at runtime. I had never written application that required dynamic dependencies. All of them was known to me while I was writing my applications. Why not use compiler as my dependency resolver.

So, I want to write decoupled and reusable methods and classes.  This can be achived partially by parameter or property Dependency Injection.

Great, but after a while you come to the moment when you must create new object that will be passed to this method or property.

What now, how can I create instance of class without coupling to concrete type, and not using IServiceProvider or static IoC Container (or worse: use reflection). Then it hit me: we can make new() constraint on generic type. That way I can write my method/class in a way that it will create instances without knowledge of concrete type. We can create really decoupled/reusable code using  generics.

 

After few tests I also created short rule:

Every time you must call new() – do it on generic type. (It doesn’t matter if it’s method or class scope generic type)

 

There is one problem with this rule – I must use default constructor - which means – I must inject all already instantiated dependencies by properties or method parameters.

Last month I had small project to create application to manage users in database where data are encrypted. It was separate, small exe file – so I thought that I test my thoughts about generics. As example of decoupled code lets see fragment of my UserCreator class:

public class UserCreator<TRepository, TCertificateStore, TCertificate, TUserLoginQuestion, TPasswordGenerator> : IUserCreator<TRepository>

    where TRepository : IRepository

    where TCertificateStore : ICertificateStore<TCertificate>, new()

    where TCertificate : ICertificate

    where TUserLoginQuestion : IQuestion, new()

    where TPasswordGenerator : IPasswordGenerator, new()

{

    public TRepository Repository { get; set; }

 

    public void CreateFirstUser()

    {

        var store = new TCertificateStore();

        var adminCert = store.CreateAdministratorCertificate();

        store.SaveAdministratorCertificate();

        var login = new TUserLoginQuestion().Ask();

        var userCert = store.CreateUserCertificate(login);

        store.SaveUserCertificate(userCert);

        var userCertBytes = userCert.ToBytes();

        Repository.CreateNewUser(login, userCert.Encrypt(Encoding.ASCII.GetBytes(new TPasswordGenerator().Generate())), userCertBytes);

        Repository.CreateNewAdministrator(userCertBytes, adminCert.Sign(userCertBytes));

    }

}

Uhh, little ugly – but (almost) completly decoupled (Encoding.ASCII.GetBytes is not important dependency in that case). To make this class more usable I created also default version

public class UserCreator : UserCreator<RepositoryDataContext, CertificateStore, Certificate, AskUserEmailForm, PasswordGenerator>{}

As you can see I can change everything this class uses to whatever implementation I want. What blows my mind is – how such small method requires so much dependencies. Below you have example of usage:

public static void Main<TRepository, TAdministratorTable, TAdministrator, TUserCreator, TLogin, TApplication>(TRepository repository)

    where TRepository : IRepository, IAdministratorRepository<TAdministratorTable, TAdministrator>

    where TAdministratorTable : IQueryable<TAdministrator>, ITable

    where TAdministrator : IAdministrator, new()

    where TUserCreator : IUserCreator<TRepository>, new()

    where TLogin : ILogin, new()

    where TApplication : IApplication, new()

{

    try

    {

        if (repository.Administrators.Count() == 0)

            new TUserCreator{Repository = repository}.CreateFirstUser();

        var login = new TLogin();

        login.Login();

        if (login.UserAuthenticated)

            new TApplication().Start();

    }

    catch(CancelException)

    {}

}

In line

            new TUserCreator{Repository = repository}.CreateFirstUser();

you can see that I must pass repository as property. It will be great if I can make a constraint for constructor other than default. For example

    where TUserCreator : IUserCreator<TRepository>, new(TRepository)

but right now I must live with a tools I have (c# 3.0). I don’t have strong opinion which is better default constructor + properties or specific constructor.

 

I was afraid that when my codebase will grow the list of dependencies will grow, especially in Main() method. What I observed instead of this was that each method require max 6-10 dependencies. Not so scary.

 

OK time for some summary:
Pros:

• Completly decoupled/reusable code
• Completly testable code
• Best performance possible (no boxing for value types)
• Free – you already have all tools – I mean you already have one tool – compiler :-)
• All dependencies are resolved by compiler
• User of your code knows all dependencies at compile time (using only intellisense)
• Because dependencies are static, they will not change in other thread (until you say so)

Cons:

• Little ugly method/class definition (I’m sure that better type inference would help here, but I’m not sure how much better is possible)
• Only constraint for default constructor is possible
• No possibility to use static methods (MS please add static virtual methods)

If anyone isintrested I’ll try to write in short time how I test such generic methods/classes. Especially how I test newly created instances. All I can say right now is that I use t4 script and Rhino Mocks.

Is it possible to write c# application without using cast?

For last few months I'm more and more fascinated with .NET generics. Especially interesting for me is a (totally academic) question: Is it possible to write application without using an cast?
While considering that option first 2 problematic cases I found was some kind of cache or ServiceProvider implementations. I even asked a question on stackoverflow.com if it's possible, but the only answer I had was that it's not or that I should have something like WeakDictionary - which probably will use cast in its implementation.

But I wouldn't be oneself if I will abandon this subject :-). As I showed in question it's possible for only one instance using static generic fields, but I can't find the solution for non static objects. After few days I think I found the solution to this - not so elegant, but it should work.

So here you have fully generic (but simplified) implementation of ServiceProvider:

    6 public class ServiceContainer : IDisposable

    7 {

    8     readonly IList<IService> services = new List<IService>();

    9 

   10     public void Add<T>(T service)

   11     {

   12         Add<T,T>(service);

   13     }

   14 

   15     public void Add<Key, T>(T service) where T : Key

   16     {

   17         services.Add(new Service<Key>(this, service));

   18     }

   19 

   20     public void Dispose()

   21     {

   22         foreach(var service in services)

   23             service.Remove(this);

   24     }

   25 

   26     ~ServiceContainer()

   27     {

   28         Dispose();

   29     }

   30 

   31     public T Get<T>()

   32     {

   33         return Service<T>.Get(this);

   34     }

   35 }

   36 

   37 public interface IService

   38 {

   39     void Remove(object parent);

   40 }

   41 

   42 public class Service<T> : IService

   43 {

   44     static readonly Dictionary<object, T> services = new Dictionary<object, T>();

   45 

   46     public Service(object parent, T service)

   47     {

   48         services.Add(parent, service);

   49     }

   50 

   51     public void Remove(object parent)

   52     {

   53         services.Remove(parent);

   54     }

   55 

   56     public static T Get(object parent)

   57     {

   58         return services[parent];

   59     }

   60 }

As you can see I store all services in static generic Dictionary, which also have information to which serviceProvider this service belong. Normally when ServiceProvider will be cleaned by Garbage Collector, all services also will be removed from memory. But because I have static field that holds them, to avoid memory leaks I'm cleaning those services in destructor/finalizer o ServiceProvider.

I see two drawbacks of this solution

• Larger memory usage due to need of having two lists of references to those services
• ServiceProvider stays one generation longer in memory than normal solution with cast, because of finalizer usage.

Now with this example Implementation of cache without cast shouldn't be so hard :-)

LATE EDIT (2009-07-30): As someone may notice from my answer on stackoverflow.com  I tried to implement such ServiceProvider but failed to do it without memory leaks. Uhh :-(

My request to microsoft: Please implement WeakReference<T>.

One instance of dataset in application and Windows Forms designer

Want to know one simple requirement that makes Windows Forms designer useles?
Here it is:

Application should use one instance of Dataset (or other component) in all windows and user controls.

Simple enough, right. So let's see it on some simple example: application that have two forms - list and the details of concrete record.
So first the list form. I've dragged the dataset table from the datasource window (in VS 2008) and it creates automagically Dataset object, datasource and gridview with apropriate databindings. Pretty amazing, huh.
Now lets go to the details form. The same way I've dragged the table but choosed that I want to see details. The same story: Dataset object, datasource and fields.
Now it seems that because we have two separate datasets in each form, the Microsoft way to fill this datasets is to fill them twice from the database (which cost bandwith),  or once from the database - on the list form - and on the details form just copy it (which costs your developement time needed for code you must write). The situation is worse if each line on the list (let say customers) have many related tables that are also needed (for example are aggregated and shown in Dataset expression columns) - you must reload/copy them all.
Another stupid effect of this default behaviour of designer is that you must first call InitilizeComponent() which binds all controls to the created empty dataset and only then you can fill/copy data making great cascade of unnecesary events that will refresh the controls and which could be avoided if we will have ability to provide already filled Dataset and then the code could databind.

The simplest solution to this problem would be to force the designer in some way to use only one instance of Dataset in all windows.
Three years ago, when I for the first time spot this problem, the only solution that came to my mind was to abandon the designer...

OK I'm joking

The only solution that I've found then was to create a method that goes through all components and rebinds all components to the new Dataset (just after InitilizeComponent()). It was ugly hack that had similiar performance like copying all needed data to the new already binded Dataset, but doesn't duplicated the data in memory.
This way I used it for three years and it somehow works.
During this time I've found that InstanceDescriptor (object that defines what code to produce in InitilizeComponent() to create your component) allows to use static methods. My happines was cooled down so fast when I saw that code generates correctly, but it makes designer to crash. I cannot find the reason for two days and I droped this path.

In the beggining of this year I owned Visual Studio 2008 and tried to write one application using WPF. I saw that it allows to use DynamicResource which behave exactly like my rebinding in windows forms. I've tried also to force it to use static method to create object, but again failed and I must say that WPF for me seems less extensive than windows forms (read -  more sealed and interal, or better - even runtime control tree has Sealed flag - lol).
I'm not convinced to WPF. Comparing to Windows Forms you must assume that you will have no designer. Nor Expression Blend, nor VS 2008 designer works for me. It ends for me that I designed only in XAML and the only preview was runtime, because designer didn't worked. For my luck this project was skipped for some time.

Right now I'm sitting on a new project back in Windows Forms and it's so much easier :-). But this time I had some free time and enough patience to sit down and find the reason why InstanceDescriptor generating static method blows away designer (of course this bug was not fixed in VS 2008 :-( ).
So in short time I've created typed Dataset called DB and my class called Data that will inherit from it to use InstanceDescriptor

[TypeConverter(typeof(OneInstanceTypeConverter<Data>))]
    [FactoryMethod(typeof(Data), "Instance")]
    public class Data : DB
    {
        static readonly Data instance = new Data();
        public static Data Instance()
        {
            return instance;
        }
    }

    public class OneInstanceTypeConverter<T> : TypeConverter
    {
        public override bool CanConvertTo(ITypeDescriptorContext context, Type destinationType)
        {
            if (destinationType == typeof(InstanceDescriptor))
                return true;
            TypeConverter converter =
                (TypeConverter) typeof (T).BaseType.GetCustomAttributes(typeof (TypeConverter), false)[0];
            return converter.CanConvertTo(context, destinationType);
        }

        public override object ConvertTo(ITypeDescriptorContext context, CultureInfo culture, object value, Type destinationType)
        {
            if (destinationType == typeof (InstanceDescriptor) && value is T)
            {
                object[] attributes = typeof (T).GetCustomAttributes(typeof (FactoryMethodAttribute), false);
                if (attributes.Length == 0)
                    return new InstanceDescriptor(typeof (T).GetConstructor(new Type[0]), null);
                return new InstanceDescriptor(((FactoryMethodAttribute)attributes[0]).Method, null, true);
            }
            TypeConverter converter =
                (TypeConverter)typeof(T).BaseType.GetCustomAttributes(typeof(TypeConverter), false)[0];
            return converter.ConvertTo(context, culture, value, destinationType);
        }        
    }

    [AttributeUsage(AttributeTargets.Class)]
    public class FactoryMethodAttribute : Attribute
    {
        private readonly MethodInfo method;

        public FactoryMethodAttribute(Type type, string method)
        {
            this.method = type.GetMethod(method, BindingFlags.Public | BindingFlags.Static);
        }

        public MethodInfo Method
        {
            get { return method; }
        }
    }

This code produces following line in InitilizeComponent():

this.data = Data.Instance();

Sweet, but when you close the form and try to open it again it will show you few exceptions that happens somwhere in CodeDomSerializer.Deserialize and says that field 'data' does not exists.
So serialization to static method works, but deserialization can't create object from it, and this is the reason I've abandoned it earlier.
Right now after two nights with Reflector and VS Debugger (of course for some reason VS 2008 didn't wanted to cooperate and load System.Design source code to debugger) I finally spot the place that have problem. But first... some theory.
When you drag some object onto form, it's created in memory and added to the designer list of objects which should be serialized to code. Later when designer is opening the file it deserializes it and calls appropriate methods to create it. usually it's a constructor, but we are trying here to call static method. What we see here is that VS can create object from constructor, but have some problem when it must call the static method. So coming this path I've checked if static method is called at all. To my lucky it was. Her is the stack trace:

HRDB.exe!Data.Instance() Line 23    C#
[Native to Managed Transition]    
[Managed to Native Transition]    
System.Design.dll!System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeExpression(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager, string name, System.CodeDom.CodeExpression expression) + 0xc25 bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.CodeDomSerializer.DeserializeStatementToInstance(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager, System.CodeDom.CodeStatement statement) + 0x6b bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.CodeDomSerializer.Deserialize(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager = {System.ComponentModel.Design.Serialization.DesignerSerializationManager}, object codeObject) + 0x114 bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.TypeCodeDomSerializer.DeserializeName(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager = {System.ComponentModel.Design.Serialization.DesignerSerializationManager}, string name = "data", System.CodeDom.CodeStatementCollection statements) + 0x300 bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.TypeCodeDomSerializer.Deserialize(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager = {System.ComponentModel.Design.Serialization.DesignerSerializationManager}, System.CodeDom.CodeTypeDeclaration declaration = {System.CodeDom.CodeTypeDeclaration}) + 0xe00 bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.CodeDomDesignerLoader.PerformLoad(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager) + 0x56 bytes    
Microsoft.VisualStudio.Design.dll!Microsoft.VisualStudio.Design.Serialization.CodeDom.VSCodeDomDesignerLoader.PerformLoad(System.ComponentModel.Design.Serialization.IDesignerSerializationManager serializationManager) + 0x2c4 bytes    
Microsoft.VisualStudio.Design.dll!Microsoft.VisualStudio.Design.Serialization.CodeDom.VSCodeDomDesignerLoader.DeferredLoadHandler.Microsoft.VisualStudio.TextManager.Interop.IVsTextBufferDataEvents.OnLoadCompleted(int fReload) + 0x48 bytes    
[Native to Managed Transition]   

I tried to find the bug somwhere in the code near the one stack trace shows me, but without success. And as a one of my ideas, I tried to comapre it to normal constructor.

HRDB.exe!HRDB.Data.Data() Line 18    C#
[Native to Managed Transition]    
[Managed to Native Transition]    
System.dll!System.SecurityUtils.SecureConstructorInvoke(System.Type type, System.Type[] argTypes, object[] args, bool allowNonPublic, System.Reflection.BindingFlags extraFlags) Line 153 + 0xc bytes    C#
System.dll!System.ComponentModel.ReflectTypeDescriptionProvider.CreateInstance(System.IServiceProvider provider, System.Type objectType = {Name = "Data" FullName = "HRDB.Data"}, System.Type[] argTypes, object[] args = {object[0]}) Line 198 + 0x11 bytes    C#
System.dll!System.ComponentModel.TypeDescriptor.TypeDescriptionNode.CreateInstance(System.IServiceProvider provider, System.Type objectType, System.Type[] argTypes, object[] args) Line 3751 + 0x10 bytes    C#
System.dll!System.ComponentModel.TypeDescriptionProvider.CreateInstance(System.IServiceProvider provider, System.Type objectType, System.Type[] argTypes, object[] args) Line 70 + 0xfffffff1 bytes    C#
System.dll!System.ComponentModel.TypeDescriptor.TypeDescriptionNode.CreateInstance(System.IServiceProvider provider, System.Type objectType, System.Type[] argTypes, object[] args) Line 3751 + 0x10 bytes    C#
System.dll!System.ComponentModel.TypeDescriptor.CreateInstance(System.IServiceProvider provider, System.Type objectType, System.Type[] argTypes, object[] args) Line 600 + 0x18 bytes    C#
System.Design.dll!System.ComponentModel.Design.DesignSurface.CreateInstance(System.Type type = {Name = "Data" FullName = "HRDB.Data"}) + 0x60 bytes    
Microsoft.VisualStudio.Design.dll!Microsoft.VisualStudio.Design.VSDesignSurface.CreateInstance(System.Type type) + 0x20 bytes    
System.Design.dll!System.ComponentModel.Design.DesignerHost.System.ComponentModel.Design.IDesignerHost.CreateComponent(System.Type componentType = {Name = "Data" FullName = "HRDB.Data"}, string name = "data") + 0xcf bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.DesignerSerializationManager.CreateInstance(System.Type type = {Name = "Data" FullName = "HRDB.Data"}, System.Collections.ICollection arguments, string name = "data", bool addToContainer = true) + 0x1fb bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.DesignerSerializationManager.System.ComponentModel.Design.Serialization.IDesignerSerializationManager.CreateInstance(System.Type type, System.Collections.ICollection arguments, string name = "data", bool addToContainer) + 0x94 bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeInstance(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager, System.Type type, object[] parameters, string name, bool addToContainer) + 0x24 bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.ComponentCodeDomSerializer.DeserializeInstance(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager = {System.ComponentModel.Design.Serialization.DesignerSerializationManager}, System.Type type, object[] parameters, string name, bool addToContainer) + 0x23 bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.CodeDomSerializerBase.DeserializeExpression(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager, string name, System.CodeDom.CodeExpression expression) + 0x550 bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.CodeDomSerializer.DeserializeStatementToInstance(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager, System.CodeDom.CodeStatement statement) + 0x6b bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.CodeDomSerializer.Deserialize(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager = {System.ComponentModel.Design.Serialization.DesignerSerializationManager}, object codeObject) + 0x114 bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.TypeCodeDomSerializer.DeserializeName(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager = {System.ComponentModel.Design.Serialization.DesignerSerializationManager}, string name = "data", System.CodeDom.CodeStatementCollection statements) + 0x300 bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.TypeCodeDomSerializer.Deserialize(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager = {System.ComponentModel.Design.Serialization.DesignerSerializationManager}, System.CodeDom.CodeTypeDeclaration declaration = {System.CodeDom.CodeTypeDeclaration}) + 0xe00 bytes    
System.Design.dll!System.ComponentModel.Design.Serialization.CodeDomDesignerLoader.PerformLoad(System.ComponentModel.Design.Serialization.IDesignerSerializationManager manager) + 0x56 bytes    
Microsoft.VisualStudio.Design.dll!Microsoft.VisualStudio.Design.Serialization.CodeDom.VSCodeDomDesignerLoader.PerformLoad(System.ComponentModel.Design.Serialization.IDesignerSerializationManager serializationManager) + 0x2c4 bytes    
Microsoft.VisualStudio.Design.dll!Microsoft.VisualStudio.Design.Serialization.CodeDom.VSCodeDomDesignerLoader.DeferredLoadHandler.Microsoft.VisualStudio.TextManager.Interop.IVsTextBufferDataEvents.OnLoadCompleted(int fReload) + 0x48 bytes    
[Native to Managed Transition]    

This one is a longer one but it shows that for normal contructor there is much more done than for static method. The paths seems to break in CodeDomSerializerBase.DeserializeExpression() method. For static method it calls the metod, but for constructor it calls ComponentCodeDomSerializer.DeserializeInstance().
Another night and I knew everything.

CodeDomSerializerBase.DeserializeExpression(IDesignerSerializationManager manager, string name, CodeExpression expression);

For static method expression parameter is CodeMethodInvokeExpression which results in just one call to System.Type.InvokeMember().
For constructor, expresion parameter is CodeObjectCreateExpression which results in call to ComponentCodeDomSerializer.DeserializeInstance() which is calling IDesignerSerializationManager.CreateInstance which apart from calling constructor is also adding created object to the list of components so it can be later used when it's refrenced in other CodeStatement.

So I've found a bug, but how to overcome it. It takes me a little time to find a way to do it without using Reflection. I was forced to create my own serializer which will exchange the CodeMethodInvokeExpression to CodeObjectCreateExpression just before deserialization. Below you have the full code:

    [DesignerSerializer(typeof(OneInstanceSerializer<Data>), typeof(CodeDomSerializer))]
    [TypeConverter(typeof(OneInstanceTypeConverter<Data>))]
    [FactoryMethod(typeof(Data), "Instance")]
    public class Data : DB
    {
        static readonly Data instance = new Data();
        public static Data Instance()
        {
            return instance;
        }
    }

    public class OneInstanceTypeConverter<T> : TypeConverter
    {
        public override bool CanConvertTo(ITypeDescriptorContext context, Type destinationType)
        {
            if (destinationType == typeof(InstanceDescriptor))
                return true;
            TypeConverter converter =
                (TypeConverter) typeof (T).BaseType.GetCustomAttributes(typeof (TypeConverter), false)[0];
            return converter.CanConvertTo(context, destinationType);
        }

        public override object ConvertTo(ITypeDescriptorContext context, CultureInfo culture, object value, Type destinationType)
        {
            if (destinationType == typeof (InstanceDescriptor) && value is T)
            {
                object[] attributes = typeof (T).GetCustomAttributes(typeof (FactoryMethodAttribute), false);
                if (attributes.Length == 0)
                    return new InstanceDescriptor(typeof (T).GetConstructor(new Type[0]), null);
                return new InstanceDescriptor(((FactoryMethodAttribute)attributes[0]).Method, null, true);
            }
            TypeConverter converter =
                (TypeConverter)typeof(T).BaseType.GetCustomAttributes(typeof(TypeConverter), false)[0];
            return converter.ConvertTo(context, culture, value, destinationType);
        }        
    }

    [AttributeUsage(AttributeTargets.Class)]
    public class FactoryMethodAttribute : Attribute
    {
        private readonly MethodInfo method;

        public FactoryMethodAttribute(Type type, string method)
        {
            this.method = type.GetMethod(method, BindingFlags.Public | BindingFlags.Static);
        }

        public MethodInfo Method
        {
            get { return method; }
        }
    }

    public class OneInstanceSerializer<T> : CodeDomSerializer
    {
        public override object Deserialize(IDesignerSerializationManager manager, object codeObject)
        {            
            CodeDomSerializer serializer = GetSerializer(manager, typeof (T).BaseType);
            CodeStatementCollection statements = codeObject as CodeStatementCollection;
            if (statements != null)
            {
                for (int i = 0; i < statements.Count; i++)
                {
                    object value = DeserializeStatementToInstance(manager, statements[i]);

                    if (value != null)
                    {
                        CodeAssignStatement statement = statements[i] as CodeAssignStatement;
                        if(statement != null)
                            statement.Right = new CodeObjectCreateExpression(typeof (T));
                        break;
                    }
                }
                return serializer.Deserialize(manager, statements);
            }

            return serializer.Deserialize(manager, codeObject);
        }

        public override object Serialize(IDesignerSerializationManager manager, object value)
        {
            return GetSerializer(manager, typeof(T).BaseType).Serialize(manager, value);
        }
    }

It's written in a way that you can just copy it and use in your project to any component you want. Just remember that you must use all 3 attributes.
I hope that it will help someone to write more performant code and still use designer to design the window in an elegant way.

I must say that - in my opinion - it's sad that windows forms style of designing will be abandon in favour of WPF and XAML. Just try to do such thing in WPF.
Wait I have better one, try to inherit from BaseForm class in WPF.
And my favourite - try to write equivalent of following generated code in WPF:

this.components = new MyContainer(this);

The key here is keyword this. I don't know how to pass Form reference in XAML. In Windows Forms it was not easy to do it, but it's possible (I'll show you later how). BTW I needed it to inject my IServiceProvider into each Form and its controls/components.

How to test static method call - Benchmarks

This is a continuation of my last post.

For a long time I rejected to even test Delegates as a method to make static method calls "virtual" because of performance. My mind doesn't allow me to accept the fact that they can be viable alternative.

But real numbers was a little strange.

First, test console program

class Program : IProgram
    {
        private static Action TestStaticDelegate = TestStatic;
        private static Action TestStaticNoInlineDelegate = TestStaticNoInline;

        static void Main(string[] args)
        {
            TestStatic();
            TestStaticNoInline();
            IProgram p = new Program();
            Action TestInterfaceDelegate = p.TestInterface;
            p.TestInterface();

            int number = 1000000000;
            
            DateTime start = DateTime.Now;
            for (int i = 0; i < number; i++ )
                TestStatic();
            Console.WriteLine("TestStatic: " + (DateTime.Now - start).Ticks);

            start = DateTime.Now;
            for (int i = 0; i < number; i++)
                TestStaticNoInline();
            Console.WriteLine("TestStaticNoInline: " + (DateTime.Now - start).Ticks);

            start = DateTime.Now;
            for (int i = 0; i < number; i++)
                p.TestInterface();
            Console.WriteLine("TestInterface: " + (DateTime.Now - start).Ticks);

            start = DateTime.Now;
            for (int i = 0; i < number; i++)
                TestStaticDelegate();
            Console.WriteLine("TestStaticDelegate: " + (DateTime.Now - start).Ticks);

            start = DateTime.Now;
            for (int i = 0; i < number; i++)
                TestStaticNoInlineDelegate();
            Console.WriteLine("TestStaticNoInlineDelegate: " + (DateTime.Now - start).Ticks);

            start = DateTime.Now;
            for (int i = 0; i < number; i++)
                TestInterfaceDelegate();
            Console.WriteLine("TestInterfaceDelegate: " + (DateTime.Now - start).Ticks);
        }

        private static int x = 0;

        static void TestStatic()
        {
            x++;
        }

        private static int y = 0;
        [MethodImpl(MethodImplOptions.NoInlining)]
        static void TestStaticNoInline()
        {
            y++;
        }

        private int z = 0;
        public void TestInterface()
        {
            z++;
        }        
    }

    public interface IProgram
    {
        void TestInterface();
    }

As you can see I want to compare static method calls with delegates and (the most important) with virtual call.
I've run this program on my AMD Athlon XP 2400+ 2GHz machine (it was Release version of course :-). The results were following:

TestStatic: 18326352
TestStaticNoInline: 39556880
TestInterface: 56280928
TestStaticDelegate: 67697344
TestStaticNoInlineDelegate: 61989136
TestInterfaceDelegate: 56180784

For me the most intresting numbers are TestInterface and TestStaticDelegate, because it compares Dependency Injection using interface with DI using Delegates. As you can see delegates are around 17% slower then interface method call. That was predictable but I've suspected much higher difference. I've run this test few times and the results was always similiar.

According to the power this method gives me, it's acceptable performance penalty, but for some strange reason I've thought that it will be interesting to test it on Intel platform also, so I've run it on my work machine with Intel Pentium 4 3 Ghz. The results were little strange:

TestStatic: 17031359
TestStaticNoInline: 61250392
TestInterface: 55000352
TestStaticDelegate: 51250328
TestStaticNoInlineDelegate: 49844069
TestInterfaceDelegate: 34218969

Woow, it seems that on Intel, Delegates are something around 7% faster then interface call. What's more, delegate instance call is 40% faster then interface one.

I've tried to find some bug in this code, but everything looks, fine for me. Event tried to change (DateTime.Now - start).Ticks to (DateTime.Now - start).ToString() but results were similiar:

TestStatic: 00:00:01.6875108
TestStaticNoInline: 00:00:06.0625388
TestInterface: 00:00:05.5312854
TestStaticDelegate: 00:00:05.0625324
TestStaticNoInlineDelegate: 00:00:05.2187834
TestInterfaceDelegate: 00:00:03.4687722

Seeing this, I saw also that even on AMD, delegate instance call (TestInterfaceDelegate) is faster then normal interface call (TestInterface).

 

My Conclusions

• If you need performance use static methods and TypeMock for testing



• If you need to inject some code at runtime you can freely use Delegates without any significant performance loose. Even better - it looks like .NET 3.5 JIT promotes functional programing (static methods and delegates) by making it more performant than object oriented (interface calls) one - at least on Intel platform.



• If you don't wan't to use TypeMock you can safely use Delegates based Dependency Injection.