How much memory does a C#/.NET object use?

You could use a memory profiler like

.NET Memory Profiler (http://memprofiler.com/)

or

CLR Profiler (free) (http://clrprofiler.codeplex.com/)

A coarse way could be this in-case you wanna know whats happening with a particular object

// Measure starting point memory use
GC_MemoryStart = System.GC.GetTotalMemory(true);

// Allocate a new byte array of 20000 elements (about 20000 bytes)
MyByteArray = new byte[20000];

// Obtain measurements after creating the new byte[]
GC_MemoryEnd = System.GC.GetTotalMemory(true);

// Ensure that the Array stays in memory and doesn't get optimized away
GC.KeepAlive(MyByteArray);

process wide stuff could be obtained perhaps like this

long Process_MemoryStart = 0;
Process MyProcess = System.Diagnostics.Process.GetCurrentProcess();
Process_MemoryStart = MyProcess.PrivateMemorySize64;

hope this helps ;)

The ANTS memory profiler will tell you exactly how much is allocated for each object/method/etc.

Here's a related post where we discussed determining the size of reference types.

You can also use WinDbg and either SOS or SOSEX (like SOS with with a lot more commands and some existing ones improved) WinDbg extensions. The command you would use to analyze an object at a particular memory address is !objsize

One VERY important item to remember is that !objsize only gives you the size of the class itself and DOES NOT necessarily include the size of the aggregate objects contained inside the class - I have no idea why it doesn't do this as it is quite frustrating and misleading at times.

I've created 2 Feature Suggestions on the Connect website that ask for this ability to be included in VisualStudio. Please vote for the items of you would like to see them added as well!

https://connect.microsoft.com/VisualStudio/feedback/details/637373/add-feature-to-debugger-to-view-an-objects-memory-footprint-usage

https://connect.microsoft.com/VisualStudio/feedback/details/637376/add-feature-to-debugger-to-view-an-objects-rooted-references

EDIT: I'm adding the following to clarify some info from the answer provided by Charles Bretana:

1. the OP asked about the size of an 'object' not a 'class'. An object is an instance of a class. Maybe this is what you meant?
2. The memory allocated for an object does not include the JITted code. The JIT code lives in its own 'JIT Code Heap'.
3. The JIT only compiles code on a method by method basis - not at a class level. So if a method never gets called for a class, it is never JIT compiled and thus never has memory allocated for it on the JIT Code Heap.

As an aside, there are about 8 different heaps that the CLR uses:

1. Loader Heap: contains CLR structures and the type system
2. High Frequency Heap: statics, MethodTables, FieldDescs, interface map
3. Low Frequency Heap: EEClass, ClassLoader and lookup tables
4. Stub Heap: stubs for CAS, COM wrappers, P/Invoke
5. Large Object Heap: memory allocations that require more than 85k bytes
6. GC Heap: user allocated heap memory private to the app
7. JIT Code Heap: memory allocated by mscoreee (Execution Engine) and the JIT compiler for managed code
8. Process/Base Heap: interop/unmanaged allocations, native memory, etc

HTH