Question

I ran into this situation today. I have an object which I’m testing for equality; the Create() method returns a subclass implementation of MyObject.

MyObject a = MyObject.Create();
MyObject b = MyObject.Create();

a == b; // is false
a.Equals(b); // is true

Note I have also over-ridden Equals() in the subclass implementation, which does a very basic check to see whether or not the passed-in object is null and is of the subclass’s type. If both those conditions are met, the objects are deemed to be equal.

The other slightly odd thing is that my unit test suite does some tests similar to

Assert.AreEqual(MyObject.Create(), MyObject.Create()); // Green bar

and the expected result is observed. Therefore I guess that NUnit uses a.Equals(b) under the covers, rather than a == b as I had assumed.

Side note: I program in a mixture of .NET and Java, so I might be mixing up my expectations/assumptions here. I thought, however, that a == b worked more consistently in .NET than it did in Java where you often have to use equals() to test equality.

UPDATE Here’s the implementation of Equals(), as requested:

public override bool Equals(object obj) {
    return obj != null && obj is MyObjectSubclass;
}

Answer 1

The key difference between == and Equals is that == (like all operators) is not polymorphic, while Equals (like any virtual function) is.

By default, reference types will get identical results for == and Equals, because they both compare references. It’s also certainly possible to code your operator logic and Equals logic entirely differently, though that seems nonsensical to do. The biggest gotcha comes when using the == (or any) operator at a higher level than the desired logic is declared (in other words, referencing the object as a parent class that either doesn’t explicitly define the operator or defines it differently than the true class). In such cases the logic for the class that it’s referenced as is used for operators, but the logic for Equals comes from whatever class the object actually is.

I want to state emphatically that, based solely upon the information in your question, there is absolutely no reason to think or assume that Equals compares values versus references. It’s trivially easy to create such a class, but this is not a language specification.

Post-question-edit edit

Your implementation of Equals will return true for any non-null instance of your class. Though the syntax makes me think that you aren’t, you may be confusing the is C# keyword (which confirms type) with the is keyword in VB.NET (which confirms referential equality). If that is indeed the case, then you can make an explicit reference comparison in C# by using Object.ReferenceEquals(this, obj).

In any case, this is why you are seeing true for Equals, since you’re passing in a non-null instance of your class.

Incidentally, your comment about NUnit using Equals is true for the same reason; because operators are not polymorphic, there would be no way for a particular class to define custom equality behavior if the Assert function used ==.