Question: Consider this code:

```
int age = 25;
short newAge = 25;
Console.WriteLine(age == newAge);  //true
Console.WriteLine(newAge.Equals(age)); //false
Console.ReadLine();

```

Both `int` and `short` are primitive types, but a comparison with `==` returns true and a comparison with `Equals` returns false.

Why?

Answer: 
Short answer:
-------------

Equality is complicated.

Detailed answer:
----------------

Primitives types override the base `object.Equals(object)` and return true if the boxed `object` is of the same **type** and value. (Note that it will also work for nullable types; non-null nullable types always box to an instance of the underlying type.)

Since `newAge` is a `short`, its `Equals(object)` method only returns true if you pass a boxed **short** with the same value. You're passing a boxed `int`, so it returns false.

By contrast, the `==` operator is defined as taking two `int`s (or `short`s or `long`s).  

When you call it with an `int` and a `short`, the compiler will implicitly convert the `short` to `int` and compare the resulting `int`s by value.

Other ways to make it work
==========================

Primitive types also have their own `Equals()` method that accepts the same type.  

If you write `age.Equals(newAge)`, the compiler will select `int.Equals(int)` as the best overload and implicitly convert `short` to `int`. It will then return `true`, since this method simply compares the `int`s directly.

`short` also has a `short.Equals(short)` method, but `int` cannot be implicitly converted to `short`, so you aren't calling it.

You could force it to call this method with a cast:

```
Console.WriteLine(newAge.Equals((short)age)); // true

```

This will call `short.Equals(short)` directly, without boxing. If `age` is larger than 32767, it will throw an overflow exception.

You could also call the `short.Equals(object)` overload, but explicitly pass a boxed object so that it gets the same type:

```
Console.WriteLine(newAge.Equals((object)(short)age)); // true

```

Like the previous alternative, this will throw an overflow if it doesn't fit in a `short`.
Unlike the previous solution, it will box the `short` into an object, wasting time and memory.

Source Code:
------------

Here are both `Equals()` methods from the actual source code:

```
    public override bool Equals(Object obj) {
        if (!(obj is Int16)) {
            return false;
        }
        return m_value == ((Int16)obj).m_value;
    }

    public bool Equals(Int16 obj)
    {
        return m_value == obj;
    }

```

Further Reading:
----------------

See [Eric Lippert](http://blog.coverity.com/2014/01/13/inconsistent-equality/).
**== In Primitive**

```
Console.WriteLine(age == newAge);          // true

```

In primitive comparison == operator behave quite obvious, In C# there are many == operator overload available.

* string == string
* int == int
* uint == uint
* long == long
* many more

So in this case there is no implicit conversion from `int` to `short` but `short` to `int` is possible. So newAge is converted into int and comparison occurs which returns true as both holds same value. So it is equivalent to:

```
Console.WriteLine(age == (int)newAge);          // true

```

**.Equals() in Primitive**

```
Console.WriteLine(newAge.Equals(age));         //false

```

Here we need to see what Equals() method is, we calling Equals with a short type variable. So there are three possibilities:

* Equals(object, object) // static method from object
* Equals(object) // virtual method from object
* Equals(short) // Implements IEquatable.Equals(short)

First type is not case here as number of arguments are different we calling with only one argument of type int. Third is also eliminated as mentioned above implicit conversion of int to short is not possible. So here Second type of `Equals(object)` is called. The `short.Equals(object)` is:

```
bool Equals(object z)
{
  return z is short && (short)z == this;
}

```

So here condition got tested `z is short` which is false as z is an int so it returns false.

[Here is detailed article from Eric Lippert](http://blog.coverity.com/2014/01/13/inconsistent-equality/#.Uw7Dys588lQ)