What is managed code and why is it important to use 100% managed code in .NET applications?
Managed code is compiled for the .NET run-time environment. It runs in the Common Language Runtime (CLR), which is the heart of the .NET Framework. The CLR provides services such as security, memory management, and cross-language integration. Managed applications written to take advantage of the features of the CLR perform more efficiently and safely, and take better advantage of developers' existing expertise in languages that support the .NET Framework.
Unmanaged code includes all application code written before the .NET Framework was introduced—this includes code written to use COM, native Win32, and Visual Basic 6. Because it does not run inside the .NET environment, unmanaged code cannot make use of any .NET managed facilities.
This tutorial reviews the benefits and advantages of using managed code in .NET applications. Managed code runs in the Common Language Runtime (CLR), which provides services such as automatic memory management, platform-neutrality, and cross-language integration.
In contrast, unmanaged code does not run inside the .NET environment and cannot use any .NET managed facilities. Unmanaged code includes all code written before the .NET Framework was introduced.
Key features available to managed code applications include:
NOTE: This document refers to functionality in the Microsoft .NET Framework 2.0. If you are using an earlier version of the .NET Framework or the DataDirect Connect® for .NET 2.2 data providers, refer to "The Importance of Managed Code in .NET Applications".
The CLR never executes Common Intermediate Language (CIL) directly. Instead, the Just-In-Time (JIT) compiler translates CIL into optimized x86 native instructions. That's why using managed code lets your software run in different environments safely and efficiently. In addition, using machine language lets you take full advantage of the features of the processor the application is running on. For example, when the JIT encounters an Intel processor, the code produced takes advantage of hyper-threading technology.
Another advantage of the JIT is improved performance. The JIT learns when the code does multiple iterations. The runtime is designed to be able to retune the JIT compiled code as your program runs.
NGEN.exe is a .NET utility that post-compiles the application at install time. Post-compiling improves start-up performance for managed code, but maintains all the security and stability advantages of managed assemblies, especially when the application uses Windows Forms. Methods are JITed when they are first used, incurring a larger startup penalty if the application calls many methods during start-up. Because Windows Forms uses many shared libraries in the operating system, post compiling Windows Forms applications usually improves performance.
Post compiling also makes sure that the application is optimized for the hardware architecture on the machine on which it is being installed.
Only when your .NET application uses components that are built using 100% managed code do you receive the full benefits of the .NET environment.
For example, when accessing data through ADO.NET, using wire protocol .NET data providers lets you preserve your managed code environment because they do not make calls to native Win32 APIs and Client pieces.
The performance advantages of the managed code environment are lost when you (or the components you are using) call unmanaged code. The CLR makes additional checks on calls to the unmanaged or native code, which impacts performance.
Unmanaged code includes the database client pieces that some .NET data providers require. Examples of .NET data providers that use both managed and unmanaged code are IBM's DB2 data provider and the Oracle Data Provider for .NET (ODP.NET). Both of these data providers must use client libraries to access the database. The data providers shipped by Microsoft for SQL Server and Oracle—as well as the Microsoft OLE DB data providers, and ODBC.NET—make calls to native Win32 database client pieces or other unmanaged code.
Another advantage of using managed code is that you can use the ClickOnce technology of the .NET Framework (see "Ease of Deployment"). However, only 100% managed code solutions can use these deployment methods effectively.
Automatic memory management is one of the most significant features of managed code. The CLR garbage collector automatically frees allocated objects when there are no longer any outstanding references to them. The developer does not need to explicitly free memory assigned to an object, which goes a long way toward reducing the amount of time spent debugging memory leaks. There can be no memory leaks in 100% managed code.
In addition, using the NGEN.exe utility to post-compile the application at install time saves memory because the JIT compiler is not running, and also preserves shared memory.
Another significant advantage of using managed code is that the CLR provides automatic lifetime management of components and modules. Lifetime control includes:
When an object is created with the new operator, the runtime allocates memory from the managed heap. Periodically, the CLR garbage collector checks the heap and automatically disposes of any objects that are no longer being used by the application, reclaiming their memory.
The garbage collector also compacts the released memory, reducing fragmentation. This function is particularly important when the application runs on large memory servers. Changing the application to use smaller objects can help to improve the effectiveness of the garbage collector. Similarly, because each DLL is assigned a 64-bit chunk of memory, combining small DLLs avoids inefficient use of memory.
Because the garbage collector automatically closes unused objects, memory leaks are not possible in an application that uses 100% managed code.
Good coding practices dictate that Close and Dispose should be used when finished with resources so that the garbage collector can function.
Thread pooling lets you make much more efficient use of multiple threads and is an important scalability feature of using managed code. The .NET Framework comes with built-in support for creating threads and using the system-provided thread pool. In particular, the ThreadPool class under the System.Threading namespace provides static methods for submitting requests to the thread pool. In managed code, if one of the threads becomes idle, the thread pool injects another worker thread into the multithread apartment to keep all the processors busy.
The standard ThreadPool methods capture the caller's stack and merge it into the stack of the thread-pool thread when the thread-pool thread starts to execute a task. If you are using unmanaged code, the entire stack will be checked, which incurs a performance cost. In some cases, you can eliminate the stack checking with the Unsafe methods ThreadPool.UnsafeQueueUserWorkItem and ThreadPool.UnsafeRegisterWaitForSingleObject, which provide better performance. However, using the Unsafe method calls does not provide complete safety.
Further adding to scalability is the ability to use a non-persistent connection with a dataset, which is a cache of the records retrieved from the database. The dataset keeps track of the state of the data and stores the data as pure XML. Database connections are opened and closed only as needed to retrieve data into the dataset, or to return updated data.
Versioning essentially eliminates "DLL hell." When you define an assembly as strongly named, the .NET executable will be executed with the same DLL with which it was built. This means that you can have side-by-side versions of a DLL, allowing you to manage shared components. Versioning ensures that each time an application starts up, it checks its shared files. If a file has changed and the changes are incompatible, the application can ask the runtime for a compatible version.
However, when an application calls unmanaged DLLs, you can end up back in "DLL hell." For example, Oracle's ODP.NET data provider calls the unmanaged Oracle Client pieces, which are specific to a particular version of Oracle. You could install two versions of this unmanaged data provider, for example, one for Oracle9i and one for the upcoming Oracle10g, but you would have a conflict, because each data provider will require a particular version of the clients. Since the clients are native Win32 DLLs, you cannot easily have side-by-side versions running on the same machine. Only with native wire protocol data providers built from 100% managed code can you install side-by-side versions with no configuration required by the end-user.
The .NET runtime automatically performs numerous checks to ensure that code is written correctly. Because these checks prevent a large number of bugs from ever happening, developer productivity is improved and the application quality is better. In addition, these checks thwart system attacks such as the exploitation of buffer overruns.
The CLR checks for type safety to ensure that applications always access allocated objects in appropriate ways. In other words, if a method input parameter is declared as accepting a 4-byte value, the common language runtime will detect and trap attempts to access the parameter as an 8-byte value. Type safety also means that execution flow will only transfer to known method entry points. There is no way to construct an arbitrary reference to a memory location and cause code at that location to begin execution. In addition, array indexes are checked to be sure they are in the range of the array. For example, if an object occupies 10 bytes in memory, the application can't change the object so that it will allow more than 10 bytes to be read.
You can write .NET applications in many different languages, such as C, C++, Visual Basic, COBOL, Fortran, Perl, Pascal, Jscript, Lisp, Python, Smalltalk, and others. Programmers can use the languages in which they are most proficient to develop portions of an application.
All CLR-compliant languages compile to Common Intermediate Language (CIL). CIL is the key to making the .NET application platform-neutral and hardware independent.
In addition, programmers can choose specific languages for specific tasks within the same application. Some languages are stronger than others for particular tasks, and programmers can choose the language best suited for the task. The originating language doesn't matter, because all .NET-compliant compilers produce CIL.
A managed .NET application can execute on any Windows platform that supports the .NET common language runtime.
In addition, with the Microsoft Mobile Internet Toolkit, developers can create a .NET compliant, mobile Web application that can be adapted to the display of multiple wireless devices.
The Microsoft .NET Framework provides a mechanism to ease the distribution and deployment of Windows applications. Whether you use ClickOnce Deployment or No-Touch Deployment depends on which version of the .NET Framework your application needs. However, only 100% managed code solutions can use these deployment methods effectively.
ClickOnce is the deployment technology in the Microsoft .NET Framework 2.0. You can create self-updating Windows-based applications that can be installed and run with minimal user interaction. When the application is updated, the changed portions can be downloaded automatically from a new side-by-side folder. Applications are self-contained, so changes to one application do not interfere with other applications. For more information, refer to the .NET Framework 2.0 SDK documentation.
Managed code does not have direct access to memory, machine registers, or pointers. The .NET Framework security enforces security restrictions on managed code that protects the code and data from being misused or damaged by other code. An administrator can define a security policy to grant or revoke permissions on an enterprise, a machine, an assembly, or a user level. For these reasons, applications that use managed code are much safer.
Code access security lets the administrator specify which operations a piece of code can perform, stopping inappropriate behavior before it can start. You can configure a complex set of rules to:
The access privileges an administrator assigns depend in part on where the application is running. For example, by default, an application that runs from the local computer has a higher level of trust and more privileges, such as accessing the file system, than an application that is running from the Internet.
Calling unmanaged code bypasses the .NET CLR security. An application that calls unmanaged code doesn't necessarily have a security problem—it simply has an open door to the possibility of problems due to the functionality of the unmanaged code that has direct access to memory or machine registers, or uses pointers. Once the unmanaged code is being executed, the CLR can no longer check it.
One common type of attack attempts to make API methods operate out of specification, causing a buffer overrun. This attack typically passes unexpected parameters, such as an out-of-range index or offset value. Managed code avoids the buffer overruns that trigger so many security snafus.
Buffer overruns usually occur in programs written in languages such as C or C++, which do not check array bounds and type safety. If an application does not check the validity of the destination buffer size and other parameters, the copied data might overrun the buffer, overwriting the data in adjacent addresses.
Buffer overruns are theoretically impossible in managed code.
Using 100% managed code gives you solid performance, improved security, and fewer bugs. The CLR provides memory management and lifetime control of objects, including scalability features and versioning.
Unmanaged code does not run inside the .NET environment. When you call unmanaged code in .NET applications, you lose many of the valuable benefits of the .NET environment. For example, ClickOnce deployment is only available for managed code applications.
DataDirect Technologies offers the following ADO.NET data providers built with 100% managed code that support the .NET Framework Version 2.0:
Existing code written for earlier versions of the .NET Framework and earlier versions of DataDirect Connect for .NET is compatible with the 3.0 version of the data providers. Note that the applications must be re-compiled using the .NET Framework 2.0.
However, if your applications require Windows 98 and Windows Me and/or the .NET Framework 1.x, you can use the DataDirect Connect for .NET 2.2 data providers, which DataDirect will continue to make available:
The following resources were used in the development of The Importance of Using 100% Managed Code