Defining Managed Code and Managed Data | The .NET and COM Interoperability Handbook (Integrated .Net)


Team-Fly

	.NET and COM Interoperability Handbook, The By Alan Gordon
	Table of Contents

	Chapter Three. Exploring the CLR

Defining Managed Code and Managed Data

Code that runs under the control of the CLR is called managed code. By targeting the CLR, managed code enjoys all the benefits that I discussed in the previous section, enhanced security, portability, and so forth.

The Official Definition of Managed Code

The "official" definition of managed code from Partition 1 (Architecture) of the Tool Developers Guide in the .NET Framework SDK Documentation is as follows :

Managed code is simply code that provides enough information to allow the CLR to provide a set of core services, including:

Given an address inside the code for a method, locate the metadata describing the method
Walk the stack
Handle exceptions
Store and retrieve security information

You can find the Tool Developer's Guide at: [Visual Studio .NET Install Directory]\ FrameworkSDK\Tool Developers Guide\docs. On my machine, the full path is: C:\Program Files\Microsoft Visual Studio .NET\FrameworkSDK\Tool Developers Guide\docs.

Only managed code can access managed data. Managed data is a special memory heap that is allocated and released automatically by the CLR through a process called garbage collection.

You can still create unmanaged code (which is the new name for the standard Win32 code you wrote before .NET) with Visual Studio .NET by creating an MFC or Active Template Library (ATL) project in the latest version of Visual C++, which is included with Visual Studio .NET.

Note

You can also create managed code with Visual C++ thanks to something called C++ with Managed Extensions. There is also talk that Microsoft will support VB 6.0 for some time to come. Because the .NET Framework represents such a fundamental shift from Win32/COM, the two platforms will likely coexist for a number of years .

Unmanaged code cannot use managed data, and it will not enjoy the benefits afforded by the CLR: garbage collection, enhanced security, simplified deployment, rich debugging support, consistent error handling, language independence, and even the possibility of running on different platforms.

I will begin our tour of the CLR by looking at types. I then talk about assemblies. In the section on assemblies, you build a multifile assembly that we will use as a running example to illustrate other concepts throughout the chapter. After I talk about assemblies at a conceptual level, I discuss the two major constituents of an assembly: metadata and MSIL. I next discuss how the CLR locates assemblies. I end the chapter by discussing garbage collection and code access security.


Team-Fly

Top