Improving performance with generic delegates in .NET

Lately I have been involved in the performance profiling work of a Windows client application, which customers had lamented to be way too slow for their taste.

The application was originally developed a couple of years ago on top of the .NET Framework 2.0. Its user interface is built using Windows Forms and it retrieves its data from a remote remote server through Web Services using ASMX.

Everything worked just fine from a functionality standpoint. However customers complained over long delays as data was being retrieved from the Web Services and slowly populated the widgets on the screen.
Something had to be done to speed things up.

Reflection is a bottleneck

A look with a .NET profiler tool such as JetBrains DotTrace revealed that a lot of time was spent sorting large collections of objects by the value of one of their properties. This would typically be done before binding them to various list controls in the UI.
The code would typically look like this and was spread out all over the code base:

// Retrieves the entire list of customers from the DAL
List<Customer> customerList = CustomerDAO.GetAll();

// Sorts the list of 'Customer' objects
// by the value of the 'FullName' property
customerList.Sort(new PropertyComparer("FullName"));

// Binds the list to a ComboBox control for display
cmbCustomers.DataSource = customerList;

Apparently line 6 was the one that takes forever to execute. Now, since the sorting algorithm used in the IList.Sort method can’t be changed from outside the class, the weak link here must be the PropertyComparer. But what is it doing? Well, here it is:

using System;
using System.Collections.Generic;
using System.Reflection;

namespace Thoughtology.Samples.Collections
{
    public class PropertyComparer<T> : IComparer<T>
    {
        private string propertyName;

        public PropertyComparer(string propertyName)
        {
            this.propertyName = propertyName;
        }

        public int Compare(T x, T y)
        {
            Type targetType = x.GetType();

            PropertyInfo targetProperty = targetType.GetProperty(propertyName);

            string xValueText = targetProperty.GetValue(x, null).ToString();
            string yValueText = targetProperty.GetValue(y, null).ToString();

            int xValueNumeric = Int32.Parse(xValueText);
            int yValueNumeric = Int32.Parse(yValueText);

            if (xValueNumeric < yValueNumeric)
            {
                return -1;
            }
            else if (xValueNumeric == yValueNumeric)
            {
                return 0;
            }
            else
            {
                return 1;
            }
        }
    }
}

Likely not the prettiest code you have ever seen. However, it’s pretty easy to see what it’s doing:

1. Extracts the value of the specified property from the input objects using reflection.
2. Converts that value to a String.
3. Parses the converted value to an Integer.
4. Compares the numeric values to decide which one is bigger.

That seems like a lot of extra work for a simple value comparison to me.

I’m sure the method was built that way for a reason. This IComparer class is designed to be “generic” and work on any type of value on any object. However my guess is that it won’t work with anything but primitive types (numbers, strings and booleans). In fact the default implementation of the Object.ToString() (used in lines 22-23) method returns the fully qualified name of the class, and that usually doesn’t isn’t much of a sorting criteria in most cases.

The real performance bottleneck here is caused by the use of reflection inside of a method that is called hundreds if not thousands of times from all over the application.

Use delegates instead

At this point it is clear that we need to refactor this class to improve its performance and still retain its original functionality, that is to provide a generic way to compare object by the value of one of their properties.

The key is to find a better way to retrieve the value of a property from any type of object without having to use reflection.

Well, since we do know the type of the objects we are comparing through the generic parameter T, we could let the caller specify which value to compare the objects with by. This can be done by having the caller pass a reference to a method, which would return that value when invoked inside of the Compare method. Let’s try it and see how it works.

Implementing the solution in .NET 2.0

Since the application was on .NET 2.0, we need to define our own delegate type that will allow callers to pass the reference to a method returning the comparable value . Here is the complete implementation of the refactored PropertyComparer class:

using System;
using System.Collections.Generic;

namespace Thoughtology.Samples.Collections
{
    public class PropertyComparer<T> : IComparer<T>
    {
        public delegate IComparable ComparableValue(T arg);

        public PropertyComparer(ComparableValue propertySelector)
        {
            this.PropertySelector = propertySelector;
        }

        public ComparableValue PropertySelector { get; set; }

        public int Compare(T x, T y)
        {
            if (this.PropertySelector == null)
            {
                throw new InvalidOperationException("PropertySelector cannot be null");
            }

            IComparable firstValue = this.PropertySelector(x);
            IComparable secondValue = this.PropertySelector(y);

            return firstValue.CompareTo(secondValue);
        }
    }
}

Our delegate, called ComparableValue, takes an object of the generic type T as input and returns a value to compare that object by.

The comparison itself is than performed by the returned value itself, by invoking the IComparable.CompareTo method on it (see line 27).

All primitive types in .NET implement the IComparable interface. Custom objects can easily be compared in a semantically meaningful way by manually implementing that same interface.

The caller can now invoke the Sort method by specifying the property to compare the items by with an anoymous delegate:

customerList.Sort(new PropertyComparer(delegate(Customer c)
    {
        return c.FullName;
    });

Notice how the property name is no longer passed a a string. Instead it is actually invoked on the object providing compile-time type checking.

Alternative implementation in .NET 3.5

This same solution can be implemented slightly differently in .NET 3.5 by taking advantage of the built in Func<T,TResult> delegate type:

using System;
using System.Collections.Generic;

namespace Thoughtology.Samples.Collections
{
    public class PropertyComparer<T> : IComparer<T>
    {
        public PropertyComparer(Func<T, IComparable> propertySelector)
        {
            this.PropertySelector = propertySelector;
        }

        public Func<T, IComparable> PropertySelector { get; set; }

        public int Compare(T x, T y)
        {
            if (this.PropertySelector == null)
            {
                throw new InvalidOperationException("PropertySelector cannot be null");
            }

            IComparable firstValue = this.PropertySelector(x);
            IComparable secondValue = this.PropertySelector(y);

            return firstValue.CompareTo(secondValue);
        }
    }
}

Great, this saved us exactly one line of code.
Don’t worry, things get much nicer on the caller’s side where the anonymous delegate is substituted by a much more compact lambda expression:

customerList.Sort(new PropertyComparer(c => c.FullName));

The results

Now that we put reflection out of the picture, it is a good time to run a simple test harness to see how the new comparison strategy performs. For this purpose we will sort an increasingly large collection of objects with the two PropertyComparer implementations and compare how long it takes to complete the operation. Here are the results in a graph:

As you see, by using delegates the sorting algorithm stays on the linear O(n). On the other hand with reflection it quickly jumps over in the exponential O(cⁿ) space, where c is the time it takes to make a single comparison.

Lessons learned

This exercise teaches three general guidelines that can be applied when programming in .NET:

• Reflection is expensive. Use it sparingly and avoid it whenever possible in code that is executed very often, such as loops.
• Generic delegates allow to build flexible code in a fast and strongly-typed fashion. This can be achieved by letting callers “inject” custom code into an algorithm by passing a delegate as argument to a method. The code referred to by the delegate will then be executed at the appropriate stage in the algorithm inside the method.
• When reflection is used to dynamically invoke members on a class, the same thing can be achieved by using generic delegates instead, like demonstrated in this article. This technique is widely used by modern isolation frameworks such as Rhino Mocks, Moq and TypeMock Isolator.

Download Sort Test Harness Sample

/Enrico

Isolating WCF through Dependency Injection – Part II

In my previous post, I talked about how to design a class that uses a WCF client proxy in such a way to make it testable in unit tests, without having to spin up a real service to answer the requests.
The technique I illustrated uses a particular Inversion of Control (IoC) principle called Dependency Injection (DI), in which objects that a given class depends on get pushed into it from the outside rather than being created internally.

In this particular case, the external dependency is represented by a WCF client proxy targeting a particular service. This approach enables me to swap the real proxy objects used in production with test doubles while running unit tests, making it possible to assert the class’s behavior in a completely isolated and controlled environment.

Moving from concrete classes to interfaces

Last time we left off with a MailClient class that takes an instance of ChannelFactory<MailServiceClientChannel> in the constructor and uses it internally every time it needs to download Email messages by following three steps:

1. Creating a new proxy instance configured to communicate with the remote MailService service
2. Invoking the GetMessages operation on the service
3. Disposing the proxy

However, as I pointed out before, being the ChannelFactory<TChannel> a concrete class, creating a test double for it isn’t very convenient. A much better approach would be having the MailClient class interact with an interface instead. This way it would be easy to create a fake factory object in unit tests and have the class use that instead of the real one.

After a quick look in the online MSDN Documentation I found that the ChannelFactory<TChannel> class indeed implements the IChannelFactory<TChannel> interface. “Sweet, I can use that!” I thought. But there’s a catch:

The IChannelFactory<TChannel>.CreateChannel factory method requires the caller to pass along an EndpointAddress object, which contains information about where and how to reach the service, like the URI and the Binding.

This isn’t really what I wanted, since it forced the MailClient class to have knowledge of where the remote service is located or at the very least how to obtain that piece of information. This doesn’t really conform to the Dependency Injection principle, since these details naturally belong to the dependent object, and should therefore be handled outside the scope of the class.

The ChannelFactory adapter

The solution I came up with is to create an adapter interface to hide these details from my class. The implementation of this interface would then wrap a properly configured instance of ChannelFactory<TChannel> and delegate all the calls it receives to it.

Here is the definition of the adapter interface:

using System.ServiceModel;

public interface IClientChannelFactory<TChannel>
    where TChannel : IClientChannel
{
    void Open(); 

    void Close(); 

    void Abort(); 

    TChannel CreateChannel();
}

And here is the default implementation:

using System;
using System.ServiceModel; 

public class ClientChannelFactory<TChannel> : IClientChannelFactory<TChannel>
    where TChannel : IClientChannel
{
    private ChannelFactory<TChannel> factory; 

    public ClientChannelFactory(string endpointConfigurationName)
    {
        this.factory = new ChannelFactory<TChannel>(endpointConfigurationName);
    } 

    public void Open()
    {
        this.factory.Open();
    } 

    public void Close()
    {
        this.factory.Close();
    } 

    public void Abort()
    {
        this.factory.Abort();
    } 

    public TChannel CreateChannel()
    {
        return this.factory.CreateChannel();
    }
}

As you can see by using generics we are able to create an implementation that works for different types of proxies.

Notice also that the class requires the callers to specify the name of the configuration element used to describe the service endpoint in the constructor. This way the MailClient class  is completely isolated from having to know about WCF configuration details, and can instead concentrate on its core responsibility, that is to invoke operations on the service and work with the results.

Here is the final MailClient implementation:

public class MailClient
{
    private IClientChannelFactory<IMailServiceClientChannel> proxyFactory; 

    public MailClient(IClientChannelFactory<IMailServiceClientChannel> proxyFactory)
    {
        this.proxyFactory = proxyFactory;
    } 

    public EmailMessage[] DownloadMessages(string smtpAddress)
    {
        // Validate the specified Email address 

        IMailServiceClientChannel proxy; 

        try
        {
            proxy = proxyFactory.CreateChannel(); 

            Mailbox request = new Mailbox(smtpAddress);
            EmailMessage[] response = proxy.GetMessages(request) 

            // Do some processing on the results 

            proxy.Close(); 

            return response;
        }
        catch(Exception e)
        {
            proxy.Abort(); 

            throw new MailClientException(&quot;Failed to download Email messages&quot;, e);
        }
    }
}

The only modification is in the type of the argument declared in the constructor, which is now an interface.

Finally unit testing

We are now able to test our class in isolation by creating fake objects that implement the IClientChannelFactory and IMailServiceClientChannel interfaces respectively, and inject them into our object under test.

In this particular example I am using Rhino Mocks as an isolation framework to create and manage test doubles, but I could as well used just about any other isolation framework out there, such as Typemock Isolator, with the same result.

using Microsoft.VisualStudio.TestTools.UnitTesting;
using Rhino.Mocks; 

[TestClass]
public class MailClientTest
{
    [TestMethod]
    public void DownloadMessages_WithValidEmailAddress_ReturnsOneMessage()
    {
        // Fakes out the WCF proxy
        var stubProxy = MockRepository.CreateStub<IMailServiceClientChannel>(); 

        // Stubs the service operation invoked by the class under test
        stubProxy
            .Stub(m => m.GetMessages(Arg<string>.Is.Anything))
            .Returns(new EmailMessage[0]);

        // Fakes out the WCF proxy factory
        var stubProxyFactory = MockRepository.CreateStub<IClientChannelFactory<IMailServiceClientChannel>>();

        // Stubs the factory method to return the mocked proxy
        stubProxyFactory
            .Stub(s => s.CreateChannel())
            .Return(stubProxy);

        var testObject = new MailClient(stubProxyFactory); 

        EmailMessage[] results = testObject.DownloadMessages("test@test.com"); 

        Assert.AreEqual(0, results.Length, "The method was not supposed to return any results");
    }
}

This concludes this short series of posts on how to apply Dependency Injection to classes that consume WCF services in order to easily test them in isolation with unit tests. I hope this helps.

/Enrico

Isolating WCF through Dependency Injection – Part I

I have to admit that in the beginning I didn’t think Inversion of Control (IoC) Containers were that big of a deal. The idea of relying on an external agent to manage all the associations between objects in an application, sounded like it would bring more problems than advantages. Overkill. But I was wrong.

Since I began using IoC containers in my projects, I found that it naturally leads to loosely-coupled structures in the software. 
This is due to two key design principles that an IoC container will enforce you to follow:

• Classes must explicitly state their dependencies with other classes as part of their public interface.
• Classes never interact with each other directly, but only through interfaces that describe a set of capabilities in an abstract manner.

This decoupling contributes in making the software easily testable and ready for evolution.

Giving up control of WCF clients

In my last project I was designing classes that would need to interact with different Web Services through WCF client proxies.
I needed to test those classes in isolation in my unit tests, without having to have my WCF service host process running in the background, so I figured I would let an instance of a WCF proxy be pushed from outside the classes through an interface, as a dependency, instead of creating it internally, like I would normally do.

This idea fits well with the way tools like svcutil and Visual Studio 2008 work when generating WCF client proxies, since they create a class as well as interfaces exposing the operations that can be invoked through the proxy.

So here is my first implementation:

public class MailClient
{
    private IMailServiceClientChannel proxy;

    public MailClient(IMailServiceClientChannel proxy)
    {
        this.proxy = proxy;
    }

    public EmailMessage[] DownloadMessages(string smtpAddress)
    {
        // Validate the specified Email address

        Mailbox request = new Mailbox(smtpAddress);
        EmailMessage[] response = proxy.GetMessages(request)

        // Do some processing on the results

        return response;
    }
}

Here I am using the IMailServiceClientChannel interface that is automatically generated by Visual Studio when adding a service proxy with the Add Service Reference dialog. This interface contains the signatures of all the operations that are part of the service contract, as well as WCF-specific infrastructure methods to manage the proxy, like Open and Close.

Something is missing

This didn’t feel quite right. I was not treating the WCF proxy like I should since I was not closing it properly after being done with it, and not having any sort of error handling code.

However, at a second thought, I realized this wasn’t really the responsibility of my class. Since I wasn’t creating the proxy instance myself but was instead receiving from the outside, I couldn’t really dispose it inside my method, because it could still be needed by the caller. So here is an alternative implementation:

public class MailClient
{
    private ChannelFactory<IMailServiceClientChannel> proxyFactory;

    public MailClient(ChannelFactory<IMailServiceClientChannel> proxyFactory)
    {
        this.proxyFactory = proxyFactory;
    }

    public EmailMessage[] DownloadMessages(string smtpAddress)
    {
        // Validate the specified Email address

        IMailServiceClientChannel proxy;

        try
        {
            proxy = proxyFactory.CreateChannel();

            Mailbox request = new Mailbox(smtpAddress);
            EmailMessage[] response = proxy.GetMessages(request)

            // Do some processing on the results

            proxy.Close();

            return response;
        }
        catch(Exception e)
        {
            proxy.Abort();

            throw new MailClientException("Failed to download Email messages", e);
        }
    }
}

This time instead of using a proxy instance, the class receives a ChannelFactory instance as an external dependency through the constructor.

Channel factories in WCF are the facilities used to create the pipelines, through which incoming and outgoing messages pass before being dispatched to the receiver or sent out over the wire.

This approach allows me to create a new proxy instances by invoking the ChannelFactory.CreateChannel method ad-hoc inside the class and to properly dispose them as soon as I no longer need them.

According to sources inside the WCF team at Microsoft, it is a best practice to create proxies by reusing the same ChannelFactory object, instead of creating a new proxy objects from the class generated by Visual Studio, since the cost of initializing the factory is paid only once.

This turns out to be a much better approach to assign WCF proxies to classes through Dependency Injection (DI) because now I can create instances of the MailClient class using my IoC of choice, which happens to be Microsoft Unity, with a couple of lines of code:

// Registers the ChannelFactory class with Unity
// and specifies the name of the endpoint to use
// as stated in the configuration file
var container = new UnityContainer();
container
    .RegisterType<ChannelFactory<IMailServiceClientChannel>>()
        .Configure<InjectedMembers>()
            .ConfigureInjectionFor<ChannelFactory<IMailServiceClientChannel>>(new InjectionConstructor("localMailServiceEndpoint"));

var client = container.Resolve<MailClient>();

// The object has now its dependencies already setup
// and is ready to be used
client.DownloadMessages("enrico@somedomain.com");

Here I’m registering the ChannelFactory class with the IoC container, telling it to pass the string “localMailServiceEndpoint” in the constructor whenever a new instance is created.
The ChannelFactory will use that value to look up in the configuration file the URL where the service is located and the protocol it should use to communicate with it, like in this sample WCF configuration:

<configuration>
    <system.serviceModel>
        <client>
            <endpoint
                name="localMailServiceEndpoint"
                address="http://localhost/mailservice"
                binding="wsHttpBinding"
                contract="IMailServiceClient" />
        </client>
    </system.serviceModel>
</configuration>

With this information in place, I’m now able to ask the container to construct an instance of the MailClient class, and it will automatically resolve the dependency on the WCF ChannelFactory for me.

What about testability?

Well, the ChannelFactory is a concrete class and, although certanly possible, can’t easily be faked out (through mocks or stubs) by using one of the common mocking isolation frameworks available out there, since it requires the presence of a configuration file with the proper WCF-specific settings in order to work correctly. This makes the MailClient class still hard to test in isolation.

In my next post I will explain a way to modify this sample to be able to write unit test for classes that use WCF proxies.

/Enrico

Another Visual Studio Color Theme

An interesting trend has emerged in the .NET community during the past couple of years, which involves developers sharing their favorite color theme for the Visual Studio code editor with their peers.

It seems the origin of this trend is somehow related to the introduction of a new feature in Visual Studio 2005 that makes it really easy to export/import all or a subset of the customizations made to the IDE’s into a single XML file. These settings files (*.vssettings) include  every configurable aspect of Visual Studio, from font colors and window sizes to keyboard shortcuts.
Useful for backups as well as for keeping Visual Studio the way you like it every time you switch to work on a different computer.

What developers are most excited about, however, is exchanging the color combinations they use for the text editor included in the IDE, referred to as “themes”.

It’s interesting to notice how a fair amount of developers seem to prefer light text on a dark background, as opposed to the traditional “black on white” paper metaphor  introduced by the word processors. These themes mimic the colors used by the classic programmer text editors of the past, like VIM and EMACS running on DOS or UNIX, which used to sport dark gray or bright blue backgrounds.

Colors are entirely a matter of personal taste, and in this regard I prefer the clean contrast of  white text on black background.
Some people even argue that dark backgrounds are easier on the eyes than white ones, due to the reduced amount of bright light emitted by the computer screens. However I don’t know of any official study conducted to scientifically prove this statement.

Being a developer myself, I also tweaked my own color theme for the text editor I use to write code on a daily basis, which in my case is Microsoft Visual Studio 2008.
I took inspiration from other themes I’ve seen around on the Internet and adjusted them to my taste. In the end, I settled for the following:

• Font: Consolas (the best-looking monospaced font when using ClearType)
• Font size: 11 pt
• Background: Black (#000000)
• Text: White (#FFFFFF)
• Keywords: Light Blue (#4B96FF)
• Classes: Orange (#E4732B)
• Interfaces: Yellow (#E5CA32)
• Value types/Enumerations: Pink (#CA95FF)
• Numbers: Green (#559762)
• Strings: Red (#E83123)
• Comments: Dark Grey (#696969)

It’s a high contrast scheme, but I feel comfortable with it since the colors are not as sharp as other similar ones like John Lam’s Vibrant Ink.

Here is how a C# file looks like with it:

And here is how an XML file looks like:

You can download my Visual Studio color theme here. I have used it for quite a while now and I am pretty satisfied with it. However, I fell I’ll probably tweak it some more in the future. After all, there is always room for improvements.

Download Thoughtology Visual Studio Dark Theme

/Enrico

Enforcing coding standards with Microsoft StyleCop

I can’t stress enough the importance of having a code convention in place before starting in any kind of software project.

What’s a code convention?

A code convention it’s about a team of developers agreeing on a standard way to statically structure the code that will be part of the system they are building together . Note that it doesn’t cover any aspect of the software design, (coupling, cohesion, dependency management and so on) but rather focuses exclusively on how the body of the code is organized.

You may wonder, how is this valuable? Well, a convention has one primary goal that goes beyond plain esthetic: to improve the code readability by achieving consistency. Following a common standard will make it easier for the members of a team to work on each other’s code without the burden of having to mentally adjust to different coding styles.

Style matters

A code convention apply to all kinds of programming elements such as declarations, expressions and statements and it usually covers different aspects. Here is a non-exclusive list of what could be described in a coding standard:

• Naming (casing, use of prefixes/suffixes)
• Ordering (where different members are defined in the context of a class)
• Comments (where they should be placed and how they should be formatted)
• Spacing (between various syntactic elements such as punctuation)

Now, making a group of developers agree on how they should format their code on such a level of detail isn’t the easiest thing in the world. We all see programming code as a way of express our minds, and that includes also how many spaces there are between the parenthesis in a method call and the list of arguments.

Verbal agreement is not enough

Even if you do succeed in finding a middle ground that makes everybody happy (or sort of), you still need to make sure that the team will stick to what has been agreed on, without relying on tedious manual code review. Luckily there are tools out there that can automatically check code against a predefined coding convention.

One of them is StyleCop, a tool internally used by many teams at Microsoft, which has been repackaged and made freely available to the public under the Shared Source license.

The package contains a set of code format rules and a command-line program that checks all the source code files in a Visual Studio project against them and provides a compliance report.
The rules that are included out-of-the-box are the lowest common denominator among different verbally defined coding standard used by many teams at Microsoft who are developing on the .NET platform using C#.

Here is a brief overview of StyleCop’s features:

• Can only check C# code (support for other languages may be added in the future)
• It integrates with Visual Studio and MSBuild, which makes it possible to run validations on demand from the IDE or as part of a build.
• The set of rules to include can be controlled with a configuration file
• Includes a graphic configuration editor (called StyleCopSettingsEditor)
• It offers an SDK that allows to extend it by adding custom rules written as .NET classes 

As mentioned, StyleCop includes a Visual Studio add-on, which allows to run it at any point in time against the currently opened project from a menu item.

By default the results of the validation are reported back to the user as warnings, but you have the option to have them show up as errors, if you care enough about consistency that is.

Configuration can be controlled via a Settings.StyleCop file, which is easily edited with the accompanying GUI editor.

StyleCop can also be run through a set of MSBuild tasks. All you have to do is include the target file that invoke the proper tasks in your custom build definition or Visual Studio project file:

<Import
Project="C:\Program Files\MSBuild\Microsoft\StyleCop\v4.3\Microsoft.StyleCop.targets" />

Resources

You can download the latest version of StyleCop from MSDN including documentation and samples. If you need more information, here you can find a good tutorial on how to successfully integrate StyleCop in your .NET project.

/Enrico

GDI memory leak in Windows Forms

A while ago I run into a rather interesting and insidious bug, which I thought I would share.

The scenario

We had a desktop application developed on the .NET Framework 2.0 using Windows Forms. Part of the requirements for this application was that the standard Windows controls had to be modified to have a custom appearance, to suite the customer’s needs. Since classes that are part of Windows Forms are really nothing more than thin managed wrappers around Windows’ graphic subsystem GDI, many customizations that required  the use of functions not directly exposed through .NET, forced us to invoke the Win32 API directly.

Now, for someone who has been developing on a virtual machine for a long time (whether it be the CLR or Java), commodities like garbage collection are quickly taken for granted. And when the time comes to step out of the safe and cozy managed world, it is easy to forget that those assumptions are no longer valid. And that’s where problems usually start.

As a side note, if we were to build the same application today we would definitely choose Windows Presentation Foundation (WPF) over Windows Forms as UI technology,  since WPF allows to easily define the controls’ visual layout separately from their functionality without leaving the CLR.

The bug

Back to our case. Our Windows Forms application would run fine under normal operations, for about 3 hours until it suddenly crashed reporting a System.OutOfMemoryException (OOM). We also noticed that the application would survive for a shorter period of time if it was used more “intensively” (meaning opening and closing a lot of forms).

By looking at the log files we could determine that the exception was always originated from the constructor of a Bitmap object, which lead us to think that we were looking at a memory leak of some sort of unmanaged graphic resources.
Like everything else in the System.Drawing and System.Windows.Forms namespaces, also the Bitmap class holds a reference to a corresponding GDI object, which is a resource allocated outside of the CLR and as such it must explicitly be released when no longer in use.
Oddly enough, a through examination of the source code confirmed that all bitmap objects were correctly released from memory by calling the Dispose method on them. So what was leaking?

To further investigate exactly what was being used and left hanging around, we used a free tool called GDIUsage, which shows exactly how many and which kinds of GDI objects are being allocated by an application. On the left picture you can see how memory looked like at application startup compared to after a couple of minutes of normal usage.

 

It was apparent that we were creating an awful lot of font objects and forgetting to delete them! But why would it take a long time for the application to crash? Were we hitting some kind of threshold?

It turned out Windows puts a limit on the number of total GDI objects that can be created inside of a process. And that limit is exactly of 10.000 GDI objects in Windows XP. This means that  allocating GDI object number 10.001 will always cause an error. You can use Task Manager to see how many GDI resources each process has currently allocated by selecting the GDI Objects column.

The solution

At this point it was a matter of tracking down where in the source code we were creating System.Drawing.Font objects. Considering the rate of growth of these fonts instinct suggested it ought to be in some kind of global function that was being called from different places in the application. Here is what we found:

[DllImport("gdi32.dll")]
private static extern IntPtr SelectObject(IntPtr hDC, IntPtr hObject);

[DllImport("gdi32.dll")]
private static extern bool DeleteObject(IntPtr hObject);

[DllImport("gdi32.dll", EntryPoint = "GetTextExtentPoint32A")]
private static extern bool GetTextExtentPoint32(
IntPtr hDC, string lpString, int cbString, ref SIZE lpSize);

[StructLayout(LayoutKind.Sequential)]
private struct SIZE
{
    int cx;
    int cy;
}

/// <summary>
/// Gets the width and height of a string with the specified font.
/// </summary>
/// <param name="g">The graphic context to measure the string.</param>
/// <param name="text">The string to be measured.</param>
/// <param name="font">The font used to display the string.</param>
/// <returns>The size of the string in width and height.</returns>
public static SizeF MeasureString(Graphics g, string text, Font font)
{
    SIZE sz = new SIZE();
    IntPtr hdc = g.GetHdc();
    IntPtr prevFont = SelectObject(hdc, font.ToHfont());

    GetTextExtentPoint32(hdc, text, text.Length, ref sz);

    DeleteObject(SelectObject(hdc, font.ToHfont()));
    g.ReleaseHdc(hdc);

    return new SizeF((float)sz.cx, (float)sz.cy);
}

Sure enough the MeauseString method was being called from all over the application (don’t ask why). Do you notice anything particularly odd in the code? Let me show you the offending line:

// The Font.ToHFont() method creates a new Font GDI object
// whose reference is being passed as argument
// to the SelectObject Win32 function
// but is never explicitly deleted
IntPtr prevFont = SelectObject(hdc, font.ToHfont());

And here is how we fixed it:

public static SizeF MeasureString(Graphics g, string text, Font font)
{
    IntPtr hdc = IntPtr.Zero;
    IntPtr f = IntPtr.Zero;
    IntPtr prevFont = IntPtr.Zero;
    SIZE sz;

    try
    {
        sz = new SIZE();
        hdc = g.GetHdc();
        f = font.ToHfont();
        prevFont = SelectObject(hdc, f);
        GetTextExtentPoint32(hdc, text, text.Length, ref sz);
    }
    finally
    {
        DeleteObject(f);
        DeleteObject(prevFont);
        g.ReleaseHdc(hdc);
    }

    return new SizeF((float)sz.cx, (float)sz.cy);
}

As you can see we made sure the DeleteObject Win32 function is called to release the Font object created by the Font.ToHFont() method.

Lessons learned

So, what did we learn from this experience? We can summarize it in 3 rules of thumb when dealing with unmanaged code in .NET, whether it be Win32, COM, you name it:

• Pay attention if any of unmanaged functions you are calling goes out and creates a new instance of some resource in memory. Carefully reading the specific API documentation is vital.
• Every time you allocate memory it is your responsibility to explicitly free it when it is no longer needed by the program. No Garbage Collector will do this for you, you are on your own.
• When creating a new unmanaged object, save a reference to it in a variable that you can use to reach that same object at a later time and remove it from memory. If you lose the reference before the object is explicitly destroyed, you have no way to reach that memory and it leaks.

I hope this rules will help you avoid some of the most common pitfalls leading to memory leaks in your own applications.

/Enrico

Managing shared cookies in WCF

Managing state across the HTTP protocol has always been one of the major challenges faced by developers when building applications on the web. Of course web services are no exception.

One way to overcome the stateless nature of HTTP without putting to much load on the web server, is to offload some of the information that has to be saved in the context of a particular conversation over to the client. The HTTP specification provides a native mechanism to do just that, by allowing web servers to bundle small pieces of textual data in a dedicated header of the response messages sent to the clients. These recognize the special payload, extract it, and store it in a local cache on disk to have it ready to be sent with every subsequent request. These small texts are technically known as “cookies”.

Cookies are opaque in ASMX

Cookies go back a long time in the history of HTTP, and have served the Internet (fairly) well so far. Sure they brought some serious security issues with them, but for the most part they have been a conventient way for developers of web sites/web  applications to save temporary pieces of information off the server and have it transparently sent back by the client with each request.
This guarantee comes from the fact that every web browser on Earth has had the notion of cookies since web browser have had built-in support for cookies for the last 15 years or so.    

However, when it comes to web services, this assumption is no longer valid, since the client isn’t necessarily a web browser and doesn’t have to know how to handle cookies.

In the ASMX programming model, this problem has a quite simple solution. The client objects used to invoke operations on a web service can optionally reference an instance of a “cookie container”, were all cookies passed back by the web server are automatically stored and sent with each request.

using System.Net;

public class Program
{
  private static void Main(string[] args)
  {
    // Creates a new instance of a client proxy for an ASMX Web service
    MyWebServiceClient client = new MyWebServiceClient();

    // Creates the cookie container and assigns it to the proxy
    CookieContainer cookieJar = new CookieContainer();
    client.CookieContainer = cookieJar;

    // From now on cookies returned by any of the web service operations
    // are automatically handled by the proxy
    client.DoSomething();
  }
}

The advantage with this approach is that it is fairly opaque to the developer, which can inspect the contents of the cookie container at any time. As a bonus, it allows the same cookie container to easily be shared between multiple clients, enabling the scenarios when same cookie is required by multiple web services.

But they are transparent in WCF

In the WCF world, things are a little bit different. WCF, being a transport-agnostic technology, doesn’t allow the concept of a cookie to be directly reflected in the high level API, since it is specific to the HTTP protocol. This translate in practice in the web service client objects not having any CookieContainer property to set and retrieve.

However this isn’t necessarily a problem, since Microsoft did put a the possibility to enable automatic “behind the scenes” cookie management for HTTP clients. This of course is implemented at the WCF binding level, and can be switched on with a configuration setting:

<system.ServiceModel>
    <bindings>
        <basicHttpBinding allowCookies="true">
    </bindings>
    <client>
        <endpoint address="http://localhost/myservice"
                  binding="basicHttpBinding"
                  contract="IMyService" />
    </client>
</system.ServiceModel>

When this option is enabled the client will make sure all cookies received from a given web service are stored and properly sent on each subsequent request in a transparent fashion. But there is a catch: the cookie is only handled in the conversation with one web service. What if you need to send the same cookies to different web services?

Well, you’ll have to explicitly set the EnableCookies setting to false  (kind of counter-intuitive I know, but required nonetheless) and start managing the cookies yourself. Luckily, there are a couple of solutions.

Ad-hoc cookie management

If you wish to manually retrieve, store and send a the same given set of cookies from two different web service client objects in WCF, you could do this ad-hoc this way:

using System.ServiceModel;
using System.ServiceModel.Channels;

public class Program
{
    private static void Main(object[] args)
    {
        string sharedCookie;

        MyWebServiceClient client = new MyWebServiceClient();

        using (new OperationContextScope(client.InnerChannel))
        {
            client.DoSomething();

            // Extract the cookie embedded in the received web service response
            // and stores it locally
            HttpResponseMessageProperty response = (HttpResponseMessageProperty)
            OperationContext.Current.IncomingMessageProperties[
                HttpResponseMessageProperty.Name];
            sharedCookie = response.Headers["Set-Cookie"];
        }

        MyOtherWebServiceClient otherClient = new MyOtherWebServiceClient();

        using (new OperationContextScope(otherClient.InnerChannel))
        {
            // Embeds the extracted cookie in the next web service request
            // Note that we manually have to create the request object since
            // since it doesn't exist yet at this stage 
            HttpRequestMessageProperty request = new HttpRequestMessageProperty();
            request.Headers["Cookie"] = sharedCookie;
            OperationContext.Current.OutgoingMessageProperties[
                HttpRequestMessageProperty.Name] = request;

            otherClient.DoSomethingElse();
        }
    }
}

 

Here we are interacting directly with the HTTP messages exchanged with the web services, reading and writing the cookies as a string in appropriate headers. In order to accomplish the task we need to use the “transport-agnostic” WCF API, which indeed makes the code more verbose compared with the ASMX example.

Centralized cookie management

In situations were cookies must be managed in the same way for all web services invoked from a client applications, your best bet is to opt for a centralized solution by applying a very useful feature in WCF: message inspectors.

Message inspectors provide a hook in the WCF messaging pipeline offering the chance to look at and possibly modify all incoming or outgoing messages that transit on the server-side as well as on the client-side. The inspectors that are registered with the WCF runtime receive the messages before they are passed on to the application or sent to the wire, depending on whether it is an incoming or outgoing message.

This way, it is possible to catch all HTTP responses coming from the web server, extract any cookies contained within the messages, and manually inject them in all subsequent HTTP requests on their way out. Here is a simplified view of the solution:

using System.ServiceModel;
using System.ServiceModel.Channels;

public class CookieManagerMessageInspector : IClientMessageInspector
{
    private string sharedCookie;

    public void AfterReceiveReply(ref Message reply, object correlationState)
    {
        HttpResponseMessageProperty httpResponse =
            reply.Properties[HttpResponseMessageProperty.Name]
            as HttpResponseMessageProperty;

        if (httpResponse != null)
        {
            string cookie = httpResponse.Headers[HttpResponseHeader.SetCookie];

            if (!string.IsNullOrEmpty(cookie))
            {
                this.sharedCookie = cookie;
            }
        }
    }

    public object BeforeSendRequest(ref Message request, IClientChannel channel)
    {
        HttpRequestMessageProperty httpRequest;

        // The HTTP request object is made available in the outgoing message only
        // when the Visual Studio Debugger is attacched to the running process
        if (!request.Properties.ContainsKey(HttpRequestMessageProperty.Name))
        {
            request.Properties.Add(HttpRequestMessageProperty.Name,
                new HttpRequestMessageProperty());
        }

        httpRequest = (HttpRequestMessageProperty)
            request.Properties[HttpRequestMessageProperty.Name];
        httpRequest.Headers.Add(HttpRequestHeader.Cookie, this.sharedCookie);

        return null;
    }
}

Message inspectors are enabled through the WCF extensibility mechanism called behaviors for single web service operations, entire web service contracts, or even specific endpoint URLs, depending on the scope the will operate in.

Here you can download a sample application showing how to implement a client-side message inspector to share the same cookies across multiple web services.

Download WCF Cookie Manager

/Enrico

Migrating ASP.NET Web Services to WCF

I am currently in the middle of a project where we are migrating a (large) amount of web services built on top of ASP.NET in .NET 2.0 (commonly referred to as ASMX Web Services) over to the Windows Communication Foundation (WCF) platform available in .NET 3.0.
The primary reason we want to do that, is because we would like to take advantage of the binary message serialization support available in WCF to speed up communication  between the services and their clients. This same technique was possible in earlier versions of the .NET Framework thanks to a technology called Remoting, which is now superceded by WCF. In both cases it requires that both the client and server run on .NET in order to work. But I digress.

Since the ASMX model has been for a long time the primary Microsoft technology for building web services on the .NET platform, I figured they must have laid out a nice migration path to bring all those web services to the new world of WCF. It turned out, they did!

The quick way

If you built your ASMX web services with code separation (that is, all programming logic resided in a separate code-behind file instead of being embedded in the ASMX file) it is possible to get an ASMX web service up and running in WCF pretty quickly by going through a few easy steps:

• Your WCF web service class no longer inherits from
  the  System.Web.Services.WebService class so remove it.
• Change the System.Web.Services.WebService attribute on the web service class to the System.ServiceModel.ServiceContract attribute.
• Change the System.Web.Services.WebMethod attribute on each web service method to the System.ServiceModel.OperationContract attribute.
• Substitute the .ASMX file with a new .SVC file with the following header:

<% @ServiceHost Service="MyNamespace.MyService" %>

• Modify the application configuration file to create a WCF endpoint that clients will use to send their requests to:

<system.serviceModel>
    <behaviors>
        <serviceBehaviors>
            <behavior name="MetadataEnabled">
                <serviceMetadata httpGetEnabled="true" />
                <serviceDebug includeExceptionDetailInFaults="true" />
            </behavior>
        </serviceBehaviors>
    </behaviors>
    <services>
        <service name="MyNamespace.MyService"
                 behaviorConfiguration="MetadataEnabled">
            <endpoint name="HttpEndpoint"
                      address=""
                      binding="wsHttpBinding"
                      contract="MyNamespace.IMyService" />
            <endpoint name="HttpMetadata"
                      address="contract"
                      binding="mexHttpBinding"
                      contract="IMetadataExchange" />
            <host>
                <baseAddresses>
                    <add baseAddress="http://localhost/myservice" />
                </baseAddresses>
            </host>
        </service>
    </services>
</system.serviceModel>

• Decorate all classes that are exchanged by the web service methods as parameters or return values with the System.RuntimeSerialization.DataContract attribute to allow them to be serialized on the wire.
• Decorate each field of the data classes with the System.RuntimeSerialization.DataMember attribute to include it in the serialized message.

Here is a summary of the changes you’ll have to make to your ASMX web service:

Where the change applies	ASMX	WCF
Web service class inheritance	WebService	-
Web service class attribute	WebServiceAttribute	ServiceContractAttribute
Web service method attribute	WebMethodAttribute	OperationContractAttribute
Data class attribute	XmlRootAttribute	DataContractAttribute
Data class field attribute	XmlElementAttribute	DataMemberAttribute
HTTP endpoint resource	.ASMX	.SVC

As a side note, if you are using .NET 3.5 SP1 the porting process gets a little easier, since WCF will automatically serialize any object that is part of a service interface without the need of any special metadata attached to it. This means you no longer have to decorate the classes and members exposed by a WCF service contract with the DataContract and DataMember attributes.

Important considerations

The simple process I just described works well for relatively simple web services, but in any real-world scenario you will have to take into consideration a few number of aspects:

• WCF services are not bound to the HTTP protocol as ASMX web services are. This means you can host them in any process you like, whether it be a Windows Service or a console application. In other words using Microsoft IIS is no longer a requirement, although it is a valid possibility in many situations.
• Even if WCF services are executed by the ASP.NET worker process when hosted in IIS, they do not participate in the ASP.NET HTTP Pipeline. This means that you have no longer access to the ASP.NET infrastructure services such as HttpContext, HttpSessionState, HttpApplicationState, ASP.NET Authorization and Impersonation in your WCF services.

So what if your ASMX web services are making extensive use of the ASP.NET session store or employ the ASP.NET security model? Is it a show-stopper?
Luckily enough, no. There is a solution to keep all that ASP.NET goodness working in WCF. It is called ASP.NET Compatibility Mode.

Backwards compatibility

Running WCF services with the ASP.NET Compatibility Mode enabled will integrate them in the ASP.NET HTTP Pipeline, which of course means all ASP.NET infrastructure will be back in place and available from WCF at runtime.
You can enable this mighty mode from WCF by following these steps:

• Decorate your web service class with the System.ServiceModel.Activation.AspNetCompatibilityRequirements attribute as following:

[AspNetCompatibilityRequirements(
    RequirementsMode = AspNetCompatibilityRequirementsMode.Required)]
public class MyService : IMyService
{
    // Service implementation
}

• Add the following setting to the application configuration file:

<system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
</system.serviceModel>

Remember that this will effectively tie the WCF runtime to the HTTP protocol, just like with ASMX web services, which means it becomes prohibited to add any non-HTTP endpoints for your WCF services.

Good luck and please, let me know your feedback!

/Enrico

Microsoft "Oslo" and the evolution of programming

The other day I was reading about one of the most talked about future Microsoft technologies code-named “Oslo”. The details of what “Oslo” is are still pretty vague, at  least until PDC 2008. In short it’s a set of technologies aimed at creating Domain Specific Languages (DSL) that can then be used to build executable programs. Yes, I know that still sounds vague, but that’s really all Microsoft has reveled about the whole project so far.

According to a recent interview on .NET Rocks! with Don Box and Doug Purdy, two of the main architects behind “Oslo”, Microsoft’s goal is to:

enable people with knowledge on a specific domain, to create software in order to solve a problem in that domain, without having to know the technical details of software construction.

To me, “Oslo” represents the next big step in the evolution of programming styles.

Imperative Programming

Traditionally computer programming has always been about “telling” the machine what to do by specifying a set of instructions to execute in a particular order. This is known as imperative programming. The way programmers expressed these instructions has evolved over time from being commands directly interpreted by CPU to higher level structured languages that used abstracted concepts instead of processor-specific instructions, and let another program, the compiler, produce the appropriate code executable by the machine. The goal of programming languages has always been to give programmers new metaphors to interact with the computer in a more intuitive and natural way. Here are a few important milestones in this evolution:

• Structured Programming: introduced natural language-like constructs to control the execution flow of program, like selection (“IF“, “ELSE“) and iteration (“WHILE“, “FOR“). Before that programmers used to construct programs by explicitly pointing to the next instruction to execute (“GOTO“).
• Procedural Programming: introduced the concept of a “routine“, an ordered set of instructions that could be executed as a group by referring to them with a name (procedure call). Routines could take input data through parameters and output results through return values. Related routines could be grouped into modules to better organize them.
• Object-Oriented Programming: focuses on the shape of the data being processed in a program. Introduced the concepts of “objects“, data structures that contain both data and the functions (methods) that operate on that data in a single unit. Objects and the interactions among them are modeled to represent real-world entities inside of a program, which allows programmers to think about a problem in a more natural way.

Declarative Programming

At the same time another style of programming has evolved over the years, known as declarative programming. Instead of telling the computer what to do, declarative programming focuses on telling what results are expected, and letting the computer figure out which steps it has to go through to obtain those results. Declarative programming expresses intent without issuing commands. Key milestones in the evolution include:

• Functional Programming: describes a program as a set of mathematical functions that operate on immutable data. Functions can have data or other functions as their input and return the result of the computation.
• Logic Programming: describes a program as a set of mathematical logic expressions. These expressions often take the form of premises and conclusions composed by logical statements (for example, “IF A AND B THEN C” where A, B, and C are logical statements). The program output is produced by evaluating these expressions on set of data called facts.
• Language Oriented Programming: focuses on constructing a domain-specific language to describe the problem in the terms of its domain, and then using that language to describe a program to solve that problem.

Microsoft “Oslo”

The technologies delivered with “Oslo” fall clearly in this last category. In “Oslo” a compiler will translate a program expressed with a domain-specific language into an imperative general-purpose programming language such as C# or Visual Basic, which in its turn gets compiled into executable machine code. This way programmers can think using even more natural metaphors, and let the computer take care of the details of how to translate their intent into running software.

/Enrico

Visual Studio Code Coverage reports with MSBuild

Recently I had a project where I was using Microsoft Visual Studio 2008 Team System for development and CruiseControl.NET for doing continuous integration. I usually care about code coverage when running unit tests, so I decided to integrate the code profiling tool included in Visual Studio Team System as part of my build process, in order to produce a code coverage report with each build.

I figured that wouldn’t be too hard, all I had to do in my build script was to invoke Visual Studio’s test runner’s executable (usually found in C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\MSTest.exe) passing an option to enable code coverage profiling, and grab the output in a file that CruiseControl.NET would later use to produce the build report.

However, I quickly found out that Visual Studio’s test runner produces code coverage output in a binary proprietary format while CruiseControl.NET uses XML in order to generate its reports. Ouch!

Luckily, Microsoft distributes a .NET API that can be used to convert the content of code coverage files produced by Visual Studio into XML. Pheeew!

The library is contained in the Microsoft.VisualStudio.Coverage.Analysis.dll assembly, which can be found in the Visual Studio 2008 Team System installation folder (usually in C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies). So all I had to do was to add an extra step in the build process to invoke that library and do the conversion.

Since I am using MSBuild to run the build, I encapsulated the code in an MSBuild task which you can find over here at the MSDN Code Gallery. There isn’t really much to it, the actual conversion is easily done in a couple of lines of code:

// You need to specify the directory containing
// the binaries that have been profiled by MSTest
CoverageInfoManager.SymPath = symbolsDirPath;
CoverageInfoManager.ExePath = symbolsDirPath;

// The input file is the binary output produced by MSTest
CoverageInfo info = CoverageInfoManager.CreateInfoFromFile(inputFilePath);
CoverageDS dataSet = info.BuildDataSet(null);
dataSet.WriteXml(outputFilePath);

Then, the task can be invoked from the MSBuild script with:

<!-- Imports the task from the assembly -->
<UsingTask TaskName="ConvertVSCoverageToXml" AssemblyFile="CI.MSBuild.Tasks.dll" />

<!-- The values of the 'OutputPath' and 'TestConfigName' variables
     must be the same as the arguments passed to MSTest.exe
     with the /resultsfile and /runconfig options -->
<ConvertVSCoverageToXml 

    CoverageFiles="$(OutputPath)\$(TestConfigName)\In\$(ComputerName)\data.coverage"

    SymbolsDirectory="$(OutputPath)\$(TestConfigName)\Out"
    OutputDirectory="$(OutputPath)" />

This could easily be achieved in much the same way with an NAnt task, if that’s your build tool of choice.

Download VSCoverageToXml MSBuild Task

/Enrico