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 application 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 services 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 understands 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 language-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 developers 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 deployment 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 boundaries; 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 deployment model that addresses customer issues with the complexities 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 Framework common language runtime adds the infrastructure necessary 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