The .NET Framework provides a run-time environment called
the Common Language Runtime, which manages the execution of
code and provides services that make the development process
easier. Compilers and tools expose the runtime?s
functionality and enable you to write code that benefits
from this managed execution environment. Code that you
develop witha language compiler that targets the runtime is
calledmanaged code; itbenefits from features such as
cross-language integration, cross-language exception
handling, enhanced security, versioning and deployment
support, a simplified model for component interaction, and
debugging and profiling services

manage code-it means the code which targets the CLR.
Unmanage code..it does not target the CLR.

1
Managed Code   is what Visual Basic .NET and C# compilers
create. It compiles to Intermediate Language (IL), not to
machine code that could run directly on your computer. The
IL is kept in a file called an assembly, along with metadata
that describes the classes, methods, and attributes (such as
security requirements) of the code you've created. This
assembly is the one-stop-shopping unit of deployment in the
.NET world. You copy it to another server to deploy the
assembly there—and often that copying is the only step
required in the deployment.
Managed code runs in the Common Language Runtime. The
runtime offers a wide variety of services to your running
code. In the usual course of events, it first loads and
verifies the assembly to make sure the IL is okay. Then,
just in time, as methods are called, the runtime arranges
for them to be compiled to machine code suitable for the
machine the assembly is running on, and caches this machine
code to be used the next time the method is called. (This is
called Just In Time, or JIT compiling, or often just Jitting.)
As the assembly runs, the runtime continues to provide
services such as security, memory management, threading, and
the like. The application is managed by the runtime.
Visual Basic .NET and C# can produce only managed code. If
you're working with those applications, you are making
managed code. Visual C++ .NET can produce managed code if
you like: When you create a project, select one of the
application types whose name starts with .Managed., such as
.Managed C++ application..

2
Unmanaged code is what you use to make before Visual Studio
.NET 2002 was released. Visual Basic 6, Visual C++ 6, heck,
even that 15-year old C compiler you may still have kicking
around on your hard drive all produced unmanaged code. It
compiled directly to machine code that ran on the machine
where you compiled it—and on other machines as long as they
had the same chip, or nearly the same. It didn't get
services such as security or memory management from an
invisible runtime; it got them from the operating system.
And importantly, it got them from the operating system
explicitly, by asking for them, usually by calling an API
provided in the Windows SDK. More recent unmanaged
applications got operating system services through COM calls.
Unlike the other Microsoft languages in Visual Studio,
Visual C++ can create unmanaged applications. When you
create a project and select an application type whose name
starts with MFC, ATL, or Win32, you're creating an unmanaged
application.
This can lead to some confusion: When you create a .Managed
C++ application., the build product is an assembly of IL
with an .exe extension. When you create an MFC application,
the build product is a Windows executable file of native
code, also with an .exe extension. The internal layout of
the two files is utterly different. You can use the
Intermediate Language Disassembler, ildasm, to look inside
an assembly and see the metadata and IL. Try pointing ildasm
at an unmanaged exe and you'll be told it has no valid CLR
(Common Language Runtime) header and can't be
disassembled—Same extension, completely different files.