Reflection

Ref: Aspect-Oriented Programming with C# and .NET [Wolfgang Schult and Andreas Polze | Hasso-Plattner-Institute at University Potsdam {wolfgang.schult|andreas.polze}@hpi.uni-potsdam.de]

Benim Notlarım

.NET defines a type system and introduces notions such as component, object, and interface, which are building blocks for distributed multi-language component-based applications.

As many other component frameworks, .NET mainly focuses on functional interfaces of components. Nonfunctional aspects of components, such as resource usage (CPU, memory), timing behavior, fault-tolerance, or security requirements are currently not expressed in .NET’s component interfaces.

There exist a number of distributed component frameworks, notably the

1. Common Object Request Broker Architecture (CORBA)
2. Microsoft’s Distributed Component Object Model (DCOM/COM+)
3. SUN’s JavaBean Model
4. .NET framework

3. Overview over the .NET Architecture

Almost a year ago, Microsoft has introduced the .NET architecture as a new component-based programming environment, which allows for easy integration of classical distributed programming techniques with Web computing. At the center of the .NET framework is an object model, called the Virtual Object System (VOS), and at center of the object model is a type system. The object model relies on basic concepts found in many objectoriented languages, such as class, inheritance, dynamic binding, class-based typing and so on. The object model is not, however, identical to the model of any of these languages. Rather, it’s an attempt to define a suitable base that bridges all these languages and others. The type system of .NET gives objects of predefined basic types, such as integers and characters, a clear place in the type system–and it provides a clean way to convert between reference and value types through "boxing" and "unboxing" operations. The result is a more coherent and regular type system than we have seen in the dominant languages so far.

Most importantly, this model is designed to be language-independent. The C# programming language directly reflects the .NET object model. NET’s focus is rather on the programming model than on any specific language. The .NET framework itself is languageindependent and attempts to provide a reasonable target to which all current languages can map. The framework enables compilers for multiple languages (namely C#, C++, VB) to share a common back end. Multilanguage component mechanisms have existed before, notably CORBA and COM. But they contain a major hurdle – one has to write an interface description in the appropriate interface definition language (IDL) for every component that you make available to the world. There is no IDL with .NET: You just use classes from other languages as if they were from your own. What this means for both component developers and component users is a dramatic simplification of the requirements put on any single development environment. You don’t need libraries addressing every application area. You provide components in your domains of expertise, where you can really bring added value. Where good libraries already exist, you benefit from them at no extra cost.

4. Metadata and Reflection in .NET

Reflection is a language mechanism, which allows access to type information during runtime. Reflection has been implemented for various object-oriented programming languages, among them Java, C#, and C++. C++ is somewhat special as it implements reflection rather as an add-on (RTTI - runtime type information) than as an inherent language feature. With .NET, reflection is not only restricted to a single language, but basically anything declared as code (any .NET assembly) can be inspected using reflection techniques. There are two variants of accessing runtime type information in .NET: the reflection classes in the common language runtime library and the unmanaged metadata interfaces.

4.1. Reflection via Runtime Library

The runtime library´s reflection classes are defined in the namespace of System.Reflection. They build on the fact that every type (class) is derived from Object. There is a public method named GetType, which has as return value an object of the type Type. This type is defined in the namespace System. Every type-instance represents one of three possible definitions:

1. · a class definition
2. · an interface definition
3. · a value-class (usually a structure)

Via reflection, one may ask about almost every type attribute, including the type’s access-modifier, whether it is a nested type and about the type’s properties.
Metadata information is structured in a hierarchical fashion. At the highest level stands the class System.Reflection.Assembly. An assembly object corresponds to one or more dynamic libraries (DLLs) from which the .NET unit in question is composed. As depicted in Figure 1, class System.Reflection.Module stands on the next lower level of the metadata hierarchy. A module represents a single DLL. This module class accepts inquiries about the types the module contains. Proceeding further down the metadata hierarchy reveals type information for any of the building blocks making up a member of the .NET virtual object system.

· method (System.Reflection.MethodInfo)
· constructor(System.Reflection.ConstructorInfo )
· property (System.Reflection.PropertyInfo)
· field (System.Reflection.FieldInfo)
· event (System.Reflection.EventInfo)

Figure 2 presents an excerpt from a C++ program, which uses reflection to display all methods of a given type (MyCalculator in our case).

4.2. The Unmanaged Metadata Interfaces

The unmanaged metadata interfaces are a collection of COM interfaces that are accessible from “outside” of the .NET environment. You can access them from any
Windows program. The interface definition can be found in the COR.H, which is contained in the platform software development kit (platform SDK). The interface
IMetaDataImport.IMetaDataAssemblyImport is used for accessing metadata on the .NET assembly level. Access to this interface is obtained via a second interface,
called IMetadataDispenser. As the name indicates, this interface “dispenses” all kinds of additional metadata interfaces, which allow read and write access to .NET metadata. Access to the metadata dispenser is obtained via calls to the COM system as depicted in Figure 3 (here as C++ Code):

The IMetaDataImport interface obtained from the OpenScope() call provides access to the .NET assembly specified in the wszFileName Argument. Information
about the structure of classes contained in that particular .NET assembly and their building blocks is now accessible via functions EnumXXX and GetXXXProps. The
first function returns an enumeration of tokens describing the metadata available, the latter one returns information about the metadata’s properties, which correspond to a particular token. In addition to the token there exists a special way of type encoding. The function GetMethodProps for example gives an array of the type PCOR_SIGNATURE as return value. This array contains the signature of the queried element. The same information can be obtained by multiple calls to EnumXXX and GetXXXProps, however, using the signatures is the more direct approach. Signatures contain only pure type information, whereas GetXXXProps methods reveal also formal parameter names.

5. A C# Attribute to express Fault-tolerance Requirements

Within this Section we are presenting a simple calculator in C# as a case study. We use the calculator as basis for a discussion on how functional (C#) and nonfunctional (aspect) code can be combined.