The LA Fox Developer Newsletter

November 2000

“. NET” (Con’t from page 4)

programming language. This runtime supplies many services

that help simplify code development and application deployment

while also improving application reliability. The .NET Framework

also includes a set of class libraries that developers can use

from any programming language. Above that sit various applica-

tion programming models that provide higher-level components

and services targeted specifically at developing Web sites and

Web Services. Now I’ll describe each of these layers.

Common Language Runtime (CLR)

The runtime loads and runs code written in any runtime-aware

programming language. Code that targets the runtime is called

managed code. Managed code simply means that there is a

defined contract of cooperation between natively executing code

and the runtime itself. Responsibility for tasks like creating

objects, making method calls, and so on is delegated to the

runtime, which enables the runtime to provide additional ser-

vices to the executing code.

The runtime features cross-language integration, self-describing

components, simple deployment and versioning, and integrated

security services. Let’s take a quick look at each of these

features.

The runtime makes use of a new common type system capable

of expressing the semantics of most modern programming

languages. The common type system defines a standard set of

types and rules for creating new types. The runtime under-

stands how to create and execute these types. Compilers and

interpreters use runtime services to define types, manage

objects, and make method calls instead of using tool or lan-

guage-specific methods.

The primary design goal for the type system is to enable deep

multilanguage integration. Code written in one language can

now inherit implementation from classes written in another

language; exceptions can be thrown from code written in one

language and caught in code written in another; and operations

such as debugging and profiling work seamlessly regardless of

the languages used to write the code. This means that develop-

ers of reusable class libraries no longer need to create versions

for each programming language or compiler, and developers

using class libraries are no longer limited to libraries developed

for the programming language they are using.

Self-describing components, which are now possible on the

Microsoft . NET Framework, simplify development and deploy-

ment and improve system reliability. Let me explain how this

works. Many services provided by the runtime are driven by

metadata, information that supplements the executable code.

Since all the information is stored together, the executables are

referred to as self-describing components.

A key advantage of self-describing components is that no other

files are needed to use the components. Separate header files

are not required for class definitions; the definitions can be

obtained from the component itself by inspecting the metadata.

Separate IDL files, type libraries, or proxy/stubs are not required

to access a component across language or process bound-

aries; the necessary information is located in the component’s

metadata. Separate configuration information does not need to

be deployed to identify developer requested service attributes.

And best of all, since the metadata is generated from the

source code during the compilation process and stored with the

executable code, it is never out of sync with the executable.

In addition to improvements in deploying individual components,

the Microsoft .NET Framework defines an application deploy-

ment model that addresses customer issues with the complexi-

ties of application installation and DLL versioning (commonly

known as “DLL Hello). Services to support this model are

provided by the runtime.

The Microsoft .NET Framework introduces the notion of an

assembly. An assembly is a group of resources and types,

along with metadata about those resources and types, that is

deployed as a unit. The metadata is called an assembly

manifest and includes information such as a list of types and

resources visible outside the assembly. The manifest also

includes information about dependencies, such as the version of

the assemblies used when the assembly was built. Developers

can specify versioning policies to indicate whether the runtime

should load the latest version of a dependent assembly installed

on the system, a specific version, or the version used at build

time.

It has always been possible for multiple copies of a software

component to reside on the same system. In general, however,

only one of these copies can be registered with the operating

system or loaded for execution. The policy for locating and

loading components is global to the system. The .NET Frame-

work common language runtime adds the infrastructure neces-

sary to support per-application policies that govern the locating

and loading of components, which is generally referred to as

side-by-side deployment.

Assemblies can be private to an application or shared by

multiple applications. Multiple versions of an assembly can be

deployed on a machine at the same time. Application configura-

(Con’t, page 6)

Figure 2 Microsoft .NET Framework Architecture

Page 5