Concerning your way to initialize the singleton, I think it will be thread safe because a static field is only populated once by the CLR. However, the problem is that the instance will be created as soon something from the class is called for the first time. Therefore, you have even less control on when the instance will be created (but that might be perfectly acceptable :)). Using a static constructor might also be problematic. In that case, the instance will be created when the class is accessed but if an exception happens in the static constructor, it will be rethrown as a TypeInitializationException which would be a bit surprising I guess. More information here.

Finally, disposing a singleton is not something I’ve seen before and I would even say that it’s probably a code-smell. As a matter of fact, I don’t think you should dispose a singleton during the lifetime of the program. You might want to reset the state of the singleton somehow, but not dispose it. If you need to dispose it before the end of the program, you might end up with dozens or hundreds of initializations of your singleton… it will be totally uncontrolled. If you’re at the end of the lifetime of the program, then it’s not really a big deal because the CLR will release all the resources for you anyway.

I have few remarks about instance initialization in singleton. Concurrency access and instance creation are often forgotten when using this design pattern. This can lead to the creation of more than one instance (but thanks to the garbage collector if available, only one will be kept).
The second remark is rather a question. The class instance can be created in class loading time with a static block like this : private static Singleton instance = new Singleton();
This creation method can solve some extra cost when managing the concurrent access to the instance, but is it safe to use it? (I have some doubts about dll loading order and instances creation).
You mention the case where we have a large number of singleton. I have noticed in the software I’m working on it is that there is no method to free the instance.

Regards

An example of …

List.Count == number of List.Items is a good one.

Another good one might be in an object that is validating data off its contingent parts ex:

I have a Customer who has a field “TotalAvailableCredit” this customer also has children “OustandingItemsOnCredit” I have an invariant that the total of all OutstandingItemsOnCredit can never total more than the TotalAvailableCredit. You can insure this invariant but it is much more difficult to insure (especially if you allow a caller to directly access the OutstandingItemsOnCredit as the invariant needs to be enforced from two objects.

One of the huge benefits of static verification is that it will manage this invariant for me. It will prove that I never break the invariant in anyway. This combined with the fact that the invariant is now exposed from the object so a consumer can understand that it will always be true is a huge benefit in terms of the caller understanding what they can expect from my code.

Cheers,

Greg

You are correct that migrations will take a long time (especially for the ultra buggy code sitting in the mainstream today). The best way to help move towards it is as you say to start writing better defensive code today. Not only will your code be better but it will be quite easy to refactor your pre/post conditions to a similar system.

One side note, everyone seems to test pre-conditions to be true but I rarely see people verifying their post conditions with an if statement in their code which is just as important.

Cheers,

Greg

*leaving another comment on invariants post*

In think that jitter optimization could be the next big area of .Net innovation, where the .net framework installation process would choose one from perhaps a dozen different jitters, each customized to a particular CPU/platform, which would generate code which would run only a machine exactly like mine.

lock (myLockObject)
{
lock (myLockObject)
{
// do my stuff
}
}

and we wouldn’t expect that to fail.