Omer van Kloeten's .NET Zen

Papa's Got a Brand New Bag

The Telligent guys came through and upgraded weblogs.asp.net to Community Server 2, as a first step in their quest to shoot some adrenaline up the community's veins.
Thanks, guys - you rock. :)

The blog now has a new look - a snowy look. Snow is nice. We don't get any here (ever), but when I did experience it, I found it calming.
I'd love to hear comments about the new look and functionality.

First post on the new engine - w00t! :D

[Updated (1.6)] Commonly Used .NET Coding Patterns in CodeDom (now under a CC license)

The latest update (1.6) of my article Commonly Used .NET Coding Patterns in CodeDom is now out.
Major changes made since 1.5:

1. The Asynchronous Operation pattern has been added.
2. The Disposable Type pattern has been added.
3. The XML Comment patterns have been added.
4. Automatic documentation of the Begin/End Process, Custom Attribute, Custom Exception, Delegate, Event, Observer, Singleton, and Typed Collection patterns.
5. The Unary operators IsNull and NotNull have been added.
6. Several bug fixes.
   
7. The work is now licensed under the Creative Commons Attribution 2.5 License: You can copy, freely distribute, derive, and even use the code in a commercial product, but you must attribute it to the author (that is, me).

As always, I'm looking for new ideas to add, so let me know if you think of anything else you'd like to add to the package.
The formatting is a little screwey, especially in the code samples, but it's ok.

Please note that the new license now permits free use of this code in commercial products. If you decide to use the library, I'd love to know about it. :)

Taking Apart The OptionalField Attribute

Version Tolerant Serialization is a very nice addition to the serialization framework. At long last, one can actually use serialization in order to save data, without worrying about breaking changes in serializable types, which cause deserialization between versions to simply not work.

After reading the above article, I turned back to read about the OptionalField attribute, which offers the ability to mark a field as new, so that when deserialization of older versions of the type happens, the field will be ignored. However, when a new serialization process (or a deserialization of a stream containing a current instance of the type) happens, it will get treated as part of the data.
What bothered me about the attribute is what the VersionAdded parameter it uses takes. It takes an integer. At first it seemed weird that the designer chose to only treat the major version of the assembly (assembly version is made up of Major, Minor, Build, and Revision), but after re-reading a few lines told me, I realized that this wasn't the case - each type now has its own version numbers!

I have to say that I personally think this is a design mistake - why would you need to save additional data about the versioning of the type, when the data about the version already exists in the serialized data? Plus, now all these new version number have to be maintained: how will I find where version 2 of my type which is now at version 8 is in my source control?

What I think is that the version parameter should have been either of the following:

1. System.Single (float) - This way, the version specified would be Major.Minor, which is, according to Microsoft's guidelines, the only part of the version which indicates (or may indicate, breaking changes):

   Changing the build number implies that the revision is a mandatory bug fix upgrade and should be installed. These so-called Quick Fix Engineering (QFE) bug fixes should be compatible with previous versions. Likewise, changing the revision number implies that only minor changes have been made, but the new version is still fully backward-compatible. Changing the minor version number implies substantial changes have been made but that backward-compatibility has been maintained whenever possible. Minor versions might include features not available in their predecessors, but older features should remain unaffected by the revision. Changing the major version number implies that the new version is substantially different from the previous version and is most likely not backward-compatible.
   - Change Management During Deployment, Microsoft Corporation

2. System.Version (through the use of System.String) - This would mean that Microsoft accepts the fact that some people like to handle their versions a little differently than what they would like to see, allowing to specify all parts of the assembly's version.
   

With either of the above, the deserialization engine would be able to alert (using an exception) if the version and the optionality of the field mismatch (e.g. version is 1.4 and the value does not exist, but the field was marked as added in version 1.3).

Another use for this would be the automatic documentation tools that could use the metadata exposed by the attribute to document the version in which the field was added (if documented).

Transactions and Anonymous Methods

Oren raised a suggestion for a new C# feature (a new trend? :D) that will include a keyword that would work like using does with try/finally, only this keyword would include try/catch/finally, in a kind of transaction (commit/rollback) fashion.

I think there isn't really a need for such a feature. One could simply do the following:

Utils.Control(delegate() {
    // code...
});

public static class Utils
{
    public static void Control(EmptyDelegate method)
    {
        try
        {
            method();
            Commit();
        }
        catch (Exception ex)
        {
            Rollback();
        }
        finally
        {
            Cleanup();
        }
    }
}

This could really simplify things, since the scope of the anonymous method is a sub-scope of the caller to Control.