Building .NET Managed Components for COM+
Modern software systems are component-based. Components make large, enterprise-wide software systems easier to manage since system functionality is divided among several components. VB.NET and all other .NET-supported languages have the ability to create these components, which can be used and reused in a variety of projects, including (but not limited to) ASP.NET projects, Windows applications, and unmanaged code (which is code that executes outside the .NET Framework).
This chapter covers the following topics:
Managed code (the code that runs on the .NET Framework) and runtime environments
The Common Language Runtime and its role in the .NET Framework
Just-in-time compilation of managed code
COM+ Component Services and its role in the .NET Framework
Creation of managed components using VB.NET
Serviced components, which take advantage of the services provided by COM+ Component Services
5.1 The Concept of Managed Code Execution
Before we get into making .NET components, we need to discuss a .NET concept called managed code. Managed code is any source code you compile that targets the .NET Framework. All the code we've examined so far in this book (ASP.NET, console applications, and so on) has been managed code.
The .NET Framework is a runtime environment in which code executes. Internal tasks, such as allocating and freeing memory, and software services (like the kinds discussed in Chapter 4) are handled by the .NET Framework as well. In general terms, a runtime environment enables user programs to take advantage of services provided by the host operating system. A runtime environment also supplies a layer of abstraction between user code and those services, through either an API or some other type of interface. Almost any program you write, regardless of the platform or language, involves interaction with a runtime environment. (An exception to this are programs written in assembly language, in which case the programmer is calling on the services of the microprocessor and memory storage in a direct, low-level fashion.)
Many programs written for the Windows platform use the C++ programming language and its runtime library. Before other languages and development systems became available, this was the only choice for developers making applications for Windows. The C/C++ runtime code shipped as a part of Windows as a series of dynamic link libraries (known as DLLs or .dll files). As a result, many Windows applications could be distributed with as little as one file, the .exe file that contained the main program code. Since no other files were required, many developers referred to these types of applications as native code applications since the preinstalled runtime code was quite small.
As new languages became available for developing Windows applications, new runtime environments needed to be developed. VB developers using version 6.0 or earlier might be aware of special support files that must be installed on the deployment computer in order for VB applications to run. These .dll files make up the VB runtime environment. Like the C/C++ runtime code mentioned above, it provides a code wrapper around operating system internals and services.
Some runtime environments provide an additional layer of abstraction over another existing runtime environment. This creates an execution environment that can exist on multiple platforms. Programs targeted to such a runtime don't compile to machine object code. Instead, they compile to another language, referred to as an intermediate language. The runtime then executes this intermediate language using an engine built for a particular operating system. The most popular type of intermediate language system is Java. The intermediate language for Java is referred to as bytecode. The .NET Framework works in a similar manner. Compiled Microsoft .NET code is referred to as Microsoft Intermediate Language (MSIL).