Components make large, enterprise-wide software systems easier to manage since system functionality is divided among several components. Learn how to use the .NET platform to create these components, which can be used and reused in a variety of projects.

This chapter is from the book

This chapter is from the book

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

Code assemblies

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).