When overriding the == operator on immutable objects, I’ve previously done something akin to

public static bool operator ==(MyThing x, MyThing y)
{
    // Null tests
    try {var ignore =  x.GetType(); } // Provoke NRE
    catch(NullReferenceException)
    {
        try
        {
            var ignore = y.GetType();
            return false; // Only one operand null
        }
        catch (NullReferenceException)
        {
            // Both operands null
            return true;
        }               
    }
    return x.Equals(y);
}

to catch the case of two null objects. (null == null) should evaluate to true. Equals, of course, evaluates if the fields of the objects are identical. However, this solution purposefully raises an exception and then catches it, which is never a good design, and also makes debugging with “break on all exceptions” a pain. So I was quite happy when I realized that the test could be written as

public static bool operator ==(MyThing x, MyThing y)
{
    // If both are null, or both are same instance, return true.
    if (System.Object.ReferenceEquals(x, y))
    {
        return true;
    }

    // If one is null, but not both, return false.
    if (((object)x == null) || ((object)y == null))
    {
        return false;
    }

    // Return true if the fields match:
    return x.Equals(y);
}

instead. I can’t take any credit for the solution above, since it’s lifted almost verbatim from Microsoft’s C# Programming Guide, Guidelines for Overloading Equals() and Operator ==. But that’s the way it always is, any information you want is always out there on the net somewhere, you just need to find it. Hopefully this post helps someone else do just that.

Ever had a problem with a IIS-hosted WCF service suddenly deciding not to work anymore, despite no apparent change has been made to your system? The culprit is probably some weird windows update, or maybe your corporation (like mine) likes to automatically distribute registry hacks that have only been tested on “clean” boxes with nothing more than Office installed, not developer boxes. Anyway, when you surf in to your service with a web browser, instead of being greeted by that nice blue/white/beige standard screen, you get your .svc file just spit back out to the browser with no interpretation at all from IIS.

There can be a dozen different reasons for this, of course, most of which can be solved by a good old fashioned

C:\WINNT\Microsoft.NET\Framework\v3.0\Windows Communication Foundation>ServiceModelReg.exe -i

to reset the IIS metabase’s scriptmappings. But sometimes that won’t do it, and one thing that’s worked for me a bunch of times, that I haven’t seen anyone else writing about, is to simply go to the Properties dialog on your service’s virtual directory, and on the ASP.NET tab switch ASP.NET version to 1.1, apply, and then switching back to 2.0. This apparently resets something useful, and your service is interpreted correctly again.

Of course, just because this works for me doesn’t mean it will work for you. Your problem may be completely different, and my solution may do nothing at all for you, and if so, don’t come complaining to me. But it’s a low-risk, fast and simple little thing that you can try if your service is acting up.