Development With A Dot

Blog on development in general, and specifically on .NET



My Friends

My Links

Permanent Posts

Portuguese Communities

September 2008 - Posts


Everyone is writing singletons and everyone thinks they know what they are doing, but what if they're wrong?

There is at least one scenario where things indeed can go wrong: serialization! SimoneB wrote about it in a blog post but I think she missed something. In fact, in .NET, there are at least two possible approaches to serialization:

While the two are similar - in fact, SoapFormatter and XmlSerializer can produce the same output - the way they work, the interfaces and attributes they rely on, are quite different:

I am assuming you know about singletons; to recall, the singleton pattern, as described in the famous Design Patterns book, is a software technique implemented to allow only a single, well known, object instance of a class. Let's start from the beginning, with a simple singleton class, shall we?

public sealed class Singleton
    private static readonly Singleton instance = new Singleton();
    private Singleton() { }

    public static Singleton Instance { get { return (instance); } }

As you can see, this class cannot be derived from since it's sealed, cannot be instantiated (except if using reflection) because it has a private constructor, and can only be accessed through its static property Instance. But if we serialize it and afterwards deserialize it, we end up with two different instances of this class! This happens because .NET does not have any intrinsic support for singletons, they are written using common OOP techniques, however, it does have intrinsic support for serialization.

Using IFormatter-implementing classes does not work, because the class is not marked with the [Serializable] attribute, so we are protected from that side, but XmlSerializer does not require the use of this attribute in order to allow serialization, so we have a problem. XmlSerializer does, however, rely on interface IXmlSerializable, so if it is implemented, it's methods are called in the course of the serialization process. If we don't want our class to be serialized, we just have to do something on each of this methods that will prevent it from happening: throw an exception!

Here is the protected version of our code:

public sealed class Singleton: IXmlSerializable
    private static readonly Singleton instance = new Singleton();

    private Singleton() {}
    public static Singleton Instance { get { return (instance); } }

    XmlSchema IXmlSerializable.GetSchema() { throw(new NotSupportedException()); }
    void IXmlSerializable.ReadXml(XmlReader reader) { throw(new NotSupportedException()); }

    void IXmlSerializable.WriteXml(XmlWriter writer) { throw(new NotSupportedException()); }

And that's it! This way, there is no easy way to have two instances of the Singleton class, unless, of course, if using reflection: the two basic serialization methods supported by .NET both fail.

Feedback, including disagreement, is welcome! :-)

Bookmark and Share
Posted: Sep 08 2008, 10:19 AM by Ricardo Peres | with 6 comment(s)
Filed under:
Pro WF: Windows Workflow in .NET 3.5

During my holidays, I started reading Pro WF: Windows Workflow in .NET 3.5, and I recommend it: it is very well written and focused. Haven't reached the more advanced part, but, for now, I am enjoying it. It is my first in-depth contact with WWF, so there are lots of thing I don't know and I am very curious to know everything there is to it!

Now, what I really miss is a chapter on SharePoint workflows! :-(

Pro WF: Windows Workflow in .NET 3.5

Bookmark and Share
Posted: Sep 01 2008, 04:14 PM by Ricardo Peres | with no comments
Filed under: , ,
Continuous Integration and Static Code Analysis

I'm about to start a new project where we'll be using JetBrain's TeamCity continuous integration. The list of features is superior to CruiseControl.NET, and it seems to have gathered a greater community of users, so I decided to give it a try. There are numerous pages which describe its configuration and features, so I will not go through that here, whenever I have something to say about it, I'll write a post.

Meanwhile, Patrick Smacchia of NDepend has been very kind and offered me a professional license of NDepend! I am very excited about this tool, but have only barely scratched it's surface, so when I have more news, I'll let you know.

I guess I'll have to update my Configuration Items List post once again... oh, well...

Bookmark and Share
More Posts