Metadata - Page 7

Metadata is defined as "data about data", and in this case you can think of it as a deeper level of data about system level attributes. Metadata is the key to the simpler programming model that the CLR supports.

The metadata is generated by a compiler and stored automatically in an EXE or DLL. It's in binary, but the framework offers an API to export metadata to and from an XML schema or a COM type library. An XML schema export might be useful, for example, in extracting version and compile information for a repository on components. Here are some of the items in the metadata defined for the .NET framework:

• Description of a deployment unit (called an assembly)

• Name, version, culture (which could determine, for example, the default user language)
• A public key for verification
• Types exported by the assembly
• Dependencies – other assemblies which this assembly depends upon
• Security permissions needed to run

• Base classes and interfaces used by the assembly

• Custom attributes

• User defined (inserted by the developer)
• Compiler defined (inserted by the compiler to indicate something special about the language)

Some of these, such as the custom attributes, are optional – the required ones are all managed automatically by the tools.

The metadata is one of the ways the CLR can support a wide variety of tools. Here are some of the possible consumers of .NET metadata:

• Designers
• Debuggers
• Profilers
• Proxy Generators
• Other compilers (to find out how to use a component in their language)
• Type / Object browsers
• Schema generators

Compilers are some of the most extensive users of metadata. For example, a compiler can examine a module produced by a different compiler and use the metadata for cross-language type import. It can also produce metadata about its own compiled modules, including such elements as flags that a module has compiled for debugging, or a language-specific marker.

Even information that might appear in a tool tip can be embedded in metadata. This extendable data store about a compiled module greatly facilitates the simpler deployment available under the .NET Framework. An API, called the Reflection API, is available for scanning and manipulation of metadata elements.

Multiple Language Integration and Support

The most ambitious aspect of the CLR is that it is designed to support multiple languages and allow unprecedented levels of integration among those languages. By enforcing a common type system, and by having complete control over interface calls, the CLR allows languages to work together more transparently than ever before.

Previously, one language could instantiate and use components written in another language by using COM. Sometimes calling conventions were difficult to manage, especially when Visual Basic was involved, but it could generally be made to work. However, subclassing a component written in a different language required a sophisticated wrapper, and only advanced developers did such work.

It is straightforward in the .NET Framework to use one language to subclass a class implemented in another language. A class written in Visual Basic can inherit from a base class written in C++, or in COBOL for that matter (at least one major vendor is at work on a COBOL implementation for .NET). The VB program doesn't even need to know the language used for the base class, and we're talking full implementation inheritance with no problems requiring recompilation when the base class changes.

How can this work? The information furnished by metadata makes it possible. There is no Interface Definition Language (IDL) in .NET because none is needed. A class interface looks the same, regardless of the language that generated it. The CLR uses metadata to manage all the interfaces and calling conventions between languages.

This has major implications; mixed language programming teams become far more feasible than before. And it becomes less necessary to force developers who are perfectly comfortable in one language to adopt another just to fit into a development effort. Cross-language inheritance promises to open up architectural options than never existed before.

One Microsoft person summed this up by saying that, as far as they are concerned, with .NET, the language used becomes a "lifestyle choice". While there will always be benefits to programming teams using a common language, .NET raises the practicality of mixed-language projects.

A Common Type System

A key piece of functionality that enables Multiple Language Support is a Common Type System, in which all commonly used data types, even base types such as Longs and Booleans, are actually implemented as objects. Coercion among types can now be done at a lower level for more consistency between languages. And, since all languages are using the same library of types, calling one language from another doesn't require type conversion or weird calling conventions.

This results in the need for some readjustment, particularly for Visual Basic developers. For example, what we called an Integer in VB6 and earlier, is now known as a Short in Visual Basic.NET. The adjustment is well worth the effort in order to bring VB in line with everything else – and, as a by- product, other languages get the same support for strings that VB has always had. (There are many details on adjustments for Visual Basic developers in Chapter 4).

Additional Key Design Goals - Page 6
Introducing .NET
Namespaces - Page 8