Jelle Druyts

I'm proud and honored to see that my first article has been published on the Microsoft Belux website:

Customizing generated Web Service proxies in Visual Studio 2005

As the title implies, it talks about how you can customize the Web Service proxies that are generated by the "Add Web Reference" dialog box in Visual Studio 2005 or the WSDL.exe tool through a new mechanism introduced in .NET 2.0 called "Schema Importer Extensions".

Don't hesitate to let me know if you liked or disliked the article or the proposed solution!

Here's a tip on how to set the default value of a color property in the Visual Studio designer.

If you have a component that has a BackColor property, for example, and you want to indicate to the Property Grid that its default color is defined as the RGB values 255/255/192 (light yellow) then you might have some trouble. You can initialize a color at runtime from these RGB values by calling Color.FromArgb(255, 255, 192), but since there's no matching constant, you can't pass this into the DefaultValueAttribute constructor:

[DefaultValue(Color.FromArgb(255, 255, 192))] // Won't compile, needs a constant value
public Color BackColor { get { ... } set { ... } }

You can try using the overloaded constructor to pass in the type of the object and an initialization string that can be parsed by a TypeConverter (just as when you type it directly into the property grid), but for some reason I've yet to discover that won't work if you use the RGB values:

[DefaultValue(typeof(Color), "255; 255; 192")] // Won't work

The trick is to use the hexadecimal value of the RGB values as such:

[DefaultValue(typeof(Color), "0xFFFFC0")] // Works, 0xFF=255, 0xFF=255, 0xC0=192

Note that you can also define system or well-known colors like this:

[DefaultValue(typeof(Color), "Red")] // Works, Red=0xFF0000

Also, check out my post on specifying default values for enums.

There's been a lot of fuss lately around the Guidelines for Test-Driven Development (TDD) that's just been published on MSDN.

I don't want to join the mud-slinging fest since I don't feel I can adequately represent the Agile community here, but this seemed like a good time to mention how I see TDD:

Test-Driven Development is like going to the grocery store with a shopping list.

Hear me out.

If you need to go grocery shopping, you can take what I'll conveniently call the "bachelor approach", which means going to the store, traversing all the aisles, throwing everything in your cart that looks remotely delicious, and not knowing in advance how much you'll wind up spending. As you mature (which is an optional step), you'll notice that you're spending way too much money on stuff you don't actually need or can't use. So in time (or until you meet someone with more experience), you'll probably start thinking in advance about what you actually need, making a list before going to the store and then buying only what's on that list. That way, you'll have a much better idea in advance what you'll be spending and as you do this more and more, you won't get caught with groceries you don't need or have to throw away.

As I see it, this is just what TDD offers: by defining the specifications for your software (the shopping list) before implementing them (actually shopping and buying), and then writing only the minimal amount of code that's necessary to meet these requirements (only buying what you have on your list), your budget will be more predictable and you lower the risk of feature creap by not going wild on features you don't need.

That said, the "bachelor approach" can of course be more fun, and yield some pleasant surprises. But in serious enterprise software development, this is often a luxury that you can't afford.

Update: Sam Gentile has just posted a more accurate definition of TDD (mine isn't 100% waterproof but I think it helps transmit the message), and Microsoft's Rob Caron has announced they'll be fixing the original article that caused the upstir. Now if Microsoft would only pull all the pages off of MSDN that show how incredibly "cool" and "productive" it is to go straight from your GUI to the database, while failing to mention that there are reasons why you would want additional layers in between. The definition of n-tier should really include the precondition "where n > 2".

Great news: David is organizing a Geek Dinner in Brussels on December 8th!

Since Microsoft blogger extraordinaire Robert Scoble and his wife Maryam will be there, let's make sure they don't forget their visit to our lovely little country and the fun community we've got going on here!

See you there!

The Singleton design pattern is one of the most widely known patterns in the software industry. In .NET 2.0, it's easy to provide a generic implementation of this pattern so you won't ever have to write the code that makes it happen again. Even though there's not much code involved, it can be tricky to get right if you consider thread safety and laziness of instantiation.

If you use the class below, accessing a singleton of any class is as simple as calling Singleton<Foo>.Instance. The Foo type only needs to support a default constructor and never worry about the details of the singleton itself. Here's the implementation of the generic Singleton class:

/// <summary>
/// Provides a global point of access to a single instance of a given class.
/// </summary>
/// <typeparam name="T">The type to provide a singleton instance for.</typeparam>
/// <remarks>
/// <para>
/// The singleton instance can be accessed through a static property,
/// where the type of the singleton is passed as a generic type parameter.
/// Subsequent requests for the instance will yield the same class instance.
/// </para>
/// <note>
/// The singleton is thread-safe and lazy (i.e. it is created when the instance
/// is first requested).
/// </note>
/// </remarks>
/// <example>
/// The following example gets a singleton instance of a <c>Foo</c> class:
/// <code>
/// Foo singleInstance = Singleton<Foo>.Instance;
/// </code>
/// </example>
public static class Singleton<T> where T : new()
{
    /// <summary>
    /// Gets the singleton instance.
    /// </summary>
    public static T Instance
    {
        get
        {
            // Thread safe, lazy implementation of the singleton pattern.
            // See http://www.yoda.arachsys.com/csharp/singleton.html
            // for the full story.
            return SingletonInternal.instance;
        }
    }

    private class SingletonInternal
    {
        // Explicit static constructor to tell C# compiler
        // not to mark type as beforefieldinit.
        static SingletonInternal()
        {
        }

        internal static readonly T instance = new T();
    }
}

Note the implementation using a private class with an explicit static constructor, this is to provide both the thread safety as the lazy instantiation. More details can be found in the "Implementing the Singleton Pattern in C#" article by Jon Skeet.