Is Everything in .Net an Object

Is everything in .NET an object?

The problem here is that this is really two questions - one question is about inheritance, in which case the answer is "nearly everything", and the other is about reference type vs value type/memory/boxing, which case the answer is "no".

Inheritance:

In C#, the following is true:

All value types, including enums and nullable types, are derived from System.Object.
All class, array, and delegate types are derived from System.Object.
Interface types are not derived from System.Object. They are all convertible to System.Object, but interfaces only derive from other interface types, and System.Object is not an interface type.
No pointer types derive from System.Object, nor are any of them directly convertible to System.Object.
"Open" type parameter types are also not derived from System.Object. Type parameter types are not derived from anything; type arguments are constrained to be derived from the effective base class, but they themselves are not "derived" from anything.

From the MSDN entry for System.Object:

Supports all classes in the .NET
Framework class hierarchy and provides
low-level services to derived classes.
This is the ultimate base class of all
classes in the .NET Framework; it is
the root of the type hierarchy.

Languages typically do not require a
class to declare inheritance from
Object because the inheritance is
implicit.

Because all classes in the .NET
Framework are derived from Object,
every method defined in the Object
class is available in all objects in
the system. Derived classes can and do
override some of these methods.

So not every type in C# is derived from System.Object. And even for those types that are, you still need to note the difference between reference types and value types, as they are treated very differently.

Boxing:

While value types do inherit from System.Object, they are treated differently in memory from reference types, and the semantics of how they are passed through methods in your code are different as well. Indeed, a value type is not treated as an Object (a reference type), until you explicitly instruct your application to do so by boxing it as a reference type. See more information about boxing in C# here.

Is int (Int32) considered an object in .NET or a primitive (not int?)?

Everything in C# inherits from object, including int.

From msdn:

Int32 is an immutable value type that represents signed integers

and

Both reference and value types are derived from the ultimate base
class Object.

When do I use 'object' in C#/.NET?

Frankly, it doesn't happen often that you REALLY need it. But when you do, it's pretty obvious. Reflection, generic type casting, serialization or tagging are among topic that ends up having object around.

It's like void*... which in essence is almost the same. You wonder what's the use for such "crude" item until you ends up in a corner with no way out, but to use it.

It's the lowest level you can find in managed code. Everything is an object, you cannot go deeper.

Generic Type casting:

public T AddComponents<T>()
{
    Component component = (Component)Activator.CreateInstance(typeof(T));

    if (component != null)
    {
        component.Parent = this;
        components.Add(component);
    }

    return (T)(object)component; //Cannot directly cast Component to T since we have no constraint between them.
}

"Tags" of the idea of assigning an item to a generic container who has no idea of the content:

public class DragDropWrapper
{
    private object tag;

    public object Tag
    {
        get { return tag; }
    }
}

What is dragged? No idea. Can be anything.

Or the very common Event Sender:

public void Message(object sender, string text)
{
    Entry entry = new Entry(sender, EntryType.Message, text);
    AddEntry(entry);
}

The sender can be anything.

Reflection to expand the property of an object:

public static List<InfoNode> ExpandObject(InfoGrid grid, InfoNode owner, object obj)
{
    List<InfoNode> nodes = new List<InfoNode>();

    if (obj == null)
        return nodes;

    PropertyInfo[] infos = obj.GetType().GetProperties(BindingFlags.FlattenHierarchy | BindingFlags.Instance | BindingFlags.Public);

    foreach (PropertyInfo info in infos)
        nodes.Add(new PropertyNode(grid, owner, obj, info));

    nodes = nodes.OrderBy(n => n.Name).ToList();

    return nodes;
}

And many many more possibilities.

Does every type in .net inherit from System.Object?

Eric Lippert has covered this in a blog entry: Not everything derives from object (This is the title of the blog entry; not the answer to this question. Don't get confused.)

Yes, all structs inherit from System.ValueType which in turn inherits from System.Object. enums you declare inherit from System.Enum which inherits from System.ValueType.

Update:

Inherently, there's not a problem with a value type being derived from a reference type. Inheritance is a "is-a" relationship between two types. However, in order to treat a value type as an object instance, it has to be boxed. This is done implicitly when you are passing a value to a method that expects an object parameter (or when you call instance methods implemented in System.Object.)

Why each class in .Net derives from System.Object? what are the benefits?

I pose the opposite question to you: why not? If not for some common ancestor, how would you have a reference to "some object of any type"? Sometimes that's needed. Really, though, the System.Object class does have some useful methods that are generally useful for any type:

Equals helps test for equality
GetHashCode helps with performance in collections
GetType - all objects have some type
Finalize to support CLR finalization

Because these things are common to all types, you can have code (even before generics) that operate intelligently on multiple types.

With that said, though, in C# 4.0, they've introduced dynamic which is really a class hierarchy of its own. It bypasses static type-checking altogether and does not necessarily derive from object. MSDN has a good article about it, and Chris Burrows' blog series is interesting as well.

Why all classes in .NET globally inherits from Object class?

The most pressing cause for Object is containers (prior to generics) which could contain anything instead of having to go C-style "Write it again for everything you need". Of course, arguably, the idea that everything should inherit from a specific class and then abusing this fact to utterly lose every speck of type safety is so terrible that it should have been a giant warning light on shipping the language without generics, and also means that Object is thoroughly redundant for new code.

Redundant to inherit from Object in C#?

If left unspecified every class definition will implicitly inherit from System.Object hence the two definitions are equivalent.

The only time these two would be different is if someone actually defined another Object type in the same namespace. In this case the local definition of Object would take precedence and change the inheritance object

namespace Example {
  class Object { } 
  class C : Object { } 
}

Very much a corner case but wouldn't point it out if I hadn't seen it before

Note that the same is not true if you used object instead of Object. The C# keyword object is a type alias for System.Object and hence it wouldn't match Example.Object.

namespace Example2 { 
  class Object { } 
  class C : Object { } // Uses Example.Object
  class D : object { } // Uses System.Object
}

Of course if you have a truly evil developer you could still cause confusion with object

namespace System { 
  class Object { 
    private Object() { } 
  }
}

namespace Example3 {
  // This will properly fail to compile since it can't bind to the private
  // Object constructor.  This demonstrates that we are using our definition
  // of Object instead of mscorlib's 
  class C : object { } // Uses our System.Object
}

Do interfaces derive from System.Object? C# spec says yes, Eric says no, reality says no

It's not quite as simple a question as you might think :)

Interfaces don't derive from object but you can call the members of object on them. So you can call ToString() on an expression which has a compile-time type of IDisposable, for example.

Coincidentally, I overhead a conversation between Neal Gafter and Eric at NDC discussing exactly this point...

I believe section 4.2.2 of the spec is over simplified, unfortunately. Hopefully Mads and Eric will fix it up for a future release - I'll mail them to make sure they see this question.

I'm also struggling to find anything in the spec to back up the rest of this answer. Section 3.4.5 of the C# 4 spec comes as close as I can find:

The members of an interface are the members declared in the interface and in all base interfaces of the interface. The members in class object are not, strictly speaking, members of any interface (13.2). However, the members in class object are available via member lookup in any interface type (7.4).

The conversion from an interface type to object is covered by section 6.1.6:

The implicit reference conversions are:

From any reference-type to object and dynamic.

System.Object being the base class

Correct, C# only allows single inheritence. The System.Object class is inherited implicitly by your Class A. So Class B is-a A, which is-a System.Object. This is taken care of by the compiler so you don't need to explicitly say that Class A : System.Object (though you can if you want).

Is Everything in .Net an Object