managed and unmanaged resources

Hi,

As Nishant says, managed resources are those that are handled by the CLR - unmanaged are not. A bit more detail:

Unmanaged Code:

Unmanaged code (or 'native' code) is generally C or C++ code, applications or binaries (dlls, exes, ocxs etc).
Unmanaged code is 'unmanaged' because the coder has to take responsibility of all memory management. Every time they want to create a new object on the heap, they must allocate memory for it and then explicitly clean it up afterwards.

This can lead to complexity, but it means expert coders can write extremely performant code. Unfortunately, non-experts may write code that has 'memory leaks' - this is when a resource or memory is allocated, but not freed when it should be - the process starts to consume more and more memory, without ever clearing parts of it up. Eventually the process will fail as it runs out of memory.

Most software you use on a PC is unmanaged - or a combination of managed and unmanaged.

Managed Code:

Code written that uses the CLR (common language runtime) is managed. C# code, Managed C++ etc. The CLR handles memory management for the coder - if asked for a resource it provides it, and automatically detects when it is no longer needed. When it is no longer needed it is marked as such and automatically cleaned up by the Garbage Collector.

This generally leads to much more straightforward code. This is not necessarily a performance hit either - poorly written managed code is much more likely to run successfully than poorly written unmanaged code - as it is very nearly impossible to get a memory leak.

Managed code can contain unmanaged code - for example you might need to directly manipulate unmanaged resources, in these cases you can handle memory management yourself.

Managed code can also use unmanaged code - this is generally referred to as Interop.



Many more resources are available, this is the gist!

Managed resources basically means "managed memory" that is managed by the garbage collector. When you no longer have any references to a managed object (which uses managed memory), the garbage collector will (eventually) release that memory for you.

Unmanaged resources are then everything that the garbage collector does not know about. For example:

* Open files
* Open network connections
* Unmanaged memory
* In XNA: vertex buffers, index buffers, textures, etc.

Normally you want to release those unmanaged resources before you lose all the references you have to the object managing them. You do this by calling Dispose on that object, or (in C#) using the using statement which will handle calling Dispose for you.

If you neglect to Dispose of your unmanaged resources correctly, the garbage collector will eventually handle it for you when the object containing that resource is garbage collected (this is "finalization"). But because the garbage collector doesn't know about the unmanaged resources, it can't tell how badly it needs to release them - so it's possible for your program to perform poorly or run out of resources entirely.

If you implement a class yourself that handles unmanaged resources, it is up to you to implement Dispose and Finalize correctly.