Reassigning to var deallocates it?

Memory useage in a programming environment like .NET is very complex under the hood, while it's extremely simplified for the developers. We refer to the time an object resides in memory as an object's "lifetime".
 
The post above this one is correct (mostly), though I think such a topic deserves a little more detail.
 
C# is what we call a garbage collected language, much like Java or Python. This means that when we develop in .NET, memory is managed for us. The thing is, how does the application know when to 'destroy' an object, and when to keep it in memory? Simple: every object you create maintains what's called a reference count, which is just a count as to "how many" references there are to a single object. The GC (garbage collector) will run whenever it "feels like it" (by feels like it, I mean the system it uses is way out of the scope of this post), and there's really no way we can predict when this will happen. When the GC does one of these "runs", it looks through the current objects allocated on the heap (any class you create with a 'new' statement, directly or indirectly, is actually allocated onto the heap). If the reference count for that object is 0, it finalizes the object (in other words, it calls the Finalize method of the object. You implement this method by supplying a destructor in C#, as opposed to actually overriding the Finalize method like you might expect). After this method has been called, the object is "marked" (not literally) as finalized. On the next pass, all objects "marked" as finalized will be removed from memory entirely.
 
Unfortunately, there is no way to explicitly remove an object from memory. You can't call an object's Finalize method, and setting a reference to null doesn't necessarily remove all references from that object. For example, the following does not ensure that the variable named "obj" will no longer exist in memory.
 
Object obj = new Object();
CallSomeMethod(obj);
obj = null;
 
CallSomeMethod is just any method that takes an object as a parameter. Now, if you're not familiar with the process, you would probably assume that obj is now no longer residing in memory, and the GC is preparing to clean it up. However, this may not actually be the case. What if CallSomeMethod added obj to a collection, or passed it to another method, which stored the reference somewhere? The object would not be eligible for garbage collection because some code could still access it, and thus, it won't be cleaned from memory, even though 'obj' points to null.
 
Unmanaged resources are a whole different story in .NET. The GC doesn't "know" how to interact with these resources; it doesn't know how to clean them up. By unmanaged resources, I mean file streams, database connections, some COM objects (for instance, a Word interop application instance), and other things. You may be thinking "but howcome if I open a FileStream and don't explicitly destroy it, it doesn't just exist forever, locking the file?" This is because the .NET developers have implemented ways to clean up the unmanaged resources on their own accord. But what about the times that we don't tell the object to clean itself up? Won't the unmanaged resources just stay in memory forever, or until the computer shuts off? The answer would be yes if the .NET developers hadn't come up with a way to make this easier on us, too. They place code that releases the unmanaged resources in the object's destructor, so when the object can no longer be referenced, it can be finalized. When it is finalized, those method(s) are called, cleaning up the resources.
 
Well, what about IDisposable, and its famous Dispose method? Surely, calling Dispose on an object should destroy it and remove it form memory! Unfortunately, this isn't the case. There is nothing special about the Dispose method--no extra code is injected into the method when you implement, nothign special happens when it is called, unless you provide that functionality. The Dispose method is just a standard throughout .NET, a good convention, that makes it easier for us to remember to clean up after ourselves when we can.
 
There is a lot more to it, but those are the 'basics'. There are a few ways in which you can interact with the GC, and they are accessed through the static class System.GC. It is usually not recommended you use these methods, as the GC usually performs much better undisturbed. However, there are some cases that you may want to communicate with the GC. For example, in most .NET Dispose methods, the object usually unregisters itself for finalization. Because nothing useful will happen in the destructor anyway (unless you put some functionality there), you can tell the GC to omit the Finalize stage, and clean the object from memory as soon as its reference count hits 0 and the GC makes its pass. You do this by calling the System.GC.SuppressFinalize(objectToSupressFinalizeFor) method. If you've ever used Red-Gate's Reflector, you've probably seen a bunch of calls to "System.GC.SupressFinalize(this);" in Dispose methods. This simply tells the GC that the destructor doesn't need to be called for this object, because you've already done your cleaning up before-hand. If you call this method on an object and want to 'cancel' this behaviour, call System.GC.ReRegisterForFinalize(objectToReRegister).
 
Though it is extremely rare, GC.Collect() can also be a useful method. It 'forces' the GC to run a pass through the objects on the heap, and evaluate whether it should remove them, finalize them or ignore them. You may find uses for some of the other methods in System.GC, but it's rather doubtful, as they're meant for very rare cases only. As I said, the GC works best when left alone. It knows how to do its job much better than you or I do.

Hope that helped,
 
Nate

I understand how GC work but don't understand the results I'm seeing with the included code, which comes from a winform app.  When button1 is clicked, I create a new class with 100 objects in it.  When button2 is clicked, I null out the class.  I never see a descrease in memory, only increases.

I also see memory increase when simply mousing over the buttons.  I'm using .NET 3.5 on Vista Home Premium 64bit.  Any ideas on the memory behavior?

    public partial class Form1 : Form
    {
        MyClass c;
        public Form1()
        {
            InitializeComponent();
        }
 
        private void button1_Click(object sender, EventArgs e)
        {
            c = new MyClass();
        }
 
        private void button2_Click(object sender, EventArgs e)
        {
            c = null;
        }
    }
 
    public class MyClass
    {
        List<object> l = new List<object>();
        public MyClass()
        {
            for (int i = 0; i < 100; i++)
            {
                l.Add(new object());
            }
        }
    }
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:

You're thinking of memory too primitively. Memory management is, by no means, simple in any way.

For example, most modern video cards (whether integrated or not) have a small processing unit, simliar to a CPU, built into the chip itself. The chip, called a GPU (Graphics Processing Unit), is geared towards graphical processing, so most graphical calls are (in theory) sent to this GPU.

Also, because you're using Windows Forms, there is a crap load of stuff you don't see going on under the hood Just because you don't subscribe to a MouseHover or MouseMove event doesn't mean the event won't be triggered when it happens. Your windows forms are accepting all messages from the mouse/keyboard at all times, whether you want them or not. Monitoring memory in the way you're attempting to is not practical, and seeing a noticeable difference is extremely unlikely (especially because an instance of an Object has no data, anyway; the reference will just but 8 bytes, in your case, being on a 64 bit system. In other words, each instance of MyClass would only take up under a kilobyte. Of course, this is only theory. This stuff may be just optimized out by the compiler completely).

If you'd like to see what goes on in your application, check out the Red-Gate Reflector. It can analyze MSIL and reconstruct it into what it may have looked like in C#, Managed C++, Delphi, MSIL Assembly, or (hate to sya this last one...) VB.NET. Very valuable tool in the scope of learning.

Why would I reconstruct it?  I have the source code.