How do you delete an object ?
The entire point of a managed language is that you dont specifically have to delete an object. You allow the memory management to do that for you. The GC (Garbage Collector) runs periodically and releases any memory that is no longer referenced by the application. So a developers main concern is to ensure that references to their objects are not redundantly maintained after they are no longer in use. Imagine creating an instance of a class and assigning it to a variable, then setting that variable to null (or you could just let it go out of scope). That object is no longer referenced and will be released when the GC runs. Do the same thing, but before setting it to null add that instance to a static collection. Now it wont be released when the GC is run. If that collection is never cleared down it will never be released, and if it is not really needed you have effectively created a memory leak. Memory management does not mean it cant leak. The point being that memory management does need to be treated with a little respect. The GC runs through the graph of the complete state of the application and releases anything that can no longer be directly accessed. It needs the developer to understand variable lifetime and the impact of the scope in which it is declared. In most cases the curly braces ({ and }) indicate scope and lifetime, but this is an over simplification, especially when you use elements of functional programming in C# and so it is worth paying attention. Certain compiler optimizations like inlining may also ultimately effect the lifetime, but it isnt something to be too concerned about unless you have very complex long running methods (which you shouldnt). Imagine an inline function that references a variable in its containing method. If the inline function is then stored elsewhere the contents of that variable are kept alive even after the containing method has gone out of scope. When the GC looks at where you have stored that function it is included with a linked reference to that variable so it can still be run. So it is still referenced by the application and will not be released. Possibly fine, you do want it still to work, but you should be aware of the side effect. This is common to all managed functional programming languages, so worth being aware of (look into Closure for more details on this subject). In 99% of cases your code will not leak and you can just ignore memory altogether. If you are writing some high performance code you can still manage your own memory using memory palettes based on byte arrays, streams or reusing structs of mutable value types. It is a myth that memory management automatically means memory inefficiency and a lack of control. If you do want to manage your own memory then do remember to implement the IDisposable interface and clean up afterwards. For high performance memory work in C# you could look into emitting IL directly into the current application at runtime. It allows you to bypass all checking and safety for absolute performance, but should be used very, very sparingly. I have used such techniques to create memory stores that perform actually slightly faster than the C++ I was replacing. So managed memory doesnt have to mean mean lame performance. Hope this helps, if not read a book on C# it should cover most of this I would expect.