+1  A: 

If you are overriding the equals method and still want to be able to check for equality (or inequality) then you should probably override the == and != methods as well.

John Boker
+1  A: 

It is not necessary, but a smart thing to do.

If you are creating a framework and another developer other than you are going to use the object you should overridet he == and !=. That way when a developer may use it they at least have the right logic to compare the 2 objects rather than just are the same in memory.

I would ensure that your == & != do call your equals method.

David Basarab
+5  A: 

See Guidelines for Implementing Equals and the Equality Operator (==)

For Value Types (structs) "Implement == any time you override the Equals method"

For Reference Types (classes), "Most reference types, even those that implement the Equals method, should not override ==." The exception is for immutable classes and those with value-like semantics.

Matt Howells
+1  A: 

It would be advisable, as it would be unexpected if:

if (foo == bar)

...behaved differently to:

if (foo.Equals(bar))
Rowland Shaw
+1  A: 

It is not necessary, nobody will kill you if you do not do that.

However, do notice that it is often more natural to write (A == B) than A.Equals(B). If you provide both methods, it will be easier for consumers of your code.

Josip Medved
+23  A: 

See the guidelines for overriding Equals() and operator==.

Quote:

By default, the operator == tests for reference equality by determining whether two references indicate the same object. Therefore, reference types do not have to implement operator == in order to gain this functionality. When a type is immutable, that is, the data that is contained in the instance cannot be changed, overloading operator == to compare value equality instead of reference equality can be useful because, as immutable objects, they can be considered the same as long as they have the same value. It is not a good idea to override operator == in non-immutable types.

Basically:

If you want == and != to behave like Equals(..) and !Equals(..) you need to implement the operators. You typically do this only with immutable types.

Lasse V. Karlsen
+1 Very clear and concise.
Andrew Hare
+1  A: 

in A.Equals(B) A cannot be null in A == B either can be null

Ted
A: 

Overriding == to make it call Equals strikes me as a generally bad idea for reference types. If you override == to make it call Equals, then I don't think there's a way for a user of your code to test whether two object references refer to the exact same object (versus an object with equal properties).

If people want to test instances of your classes for value equality then surely they should just call Equals, saving == for testing reference equality specifically.

MB