This chapter is from the book
This chapter is from the book
This chapter is from the book
5.2 The Common Language Runtime
The runtime environment for the .NET Framework is called the Common Language Runtime (CLR). Managed code execution happens inside the CLR space. The goal of the CLR is to provide an environment that includes language integration, exception handling, security, versioning, deployment, debugging, profiling, and component interaction. Most importantly, all of these features need cross-language support. In other words, all the features mentioned must work in the same manner regardless of the language used.
Metadata makes cross-language integration possible. When you compile .NET managed code, the metadata gets stored along with the object code. Metadata describes to the CLR various types of information (for example, data types, members, and references) used in the code. This data is used by the CLR to "manage" the code execution by providing such services as memory allocation, method invocation, and security enforcement. It also eases deployment since references to other objects are included along with metadata. This ensures that your application contains all up-to-date versions of all dependent components.
5.2.1 The Common Type System
Along with providing information about managed code through metadata, the CLR implements a series of data types that are cross-language compatible. That system of data types is known as the Common Type System (CTS). CTS data types include simple value types, classes, enumerated value types, interfaces, and delegates.
Simple value data types include primitive types as well as user-defined types. Primitive types include integers, Boolean values, and strings. These types are included in the System namespace. The data types used thus far in the VB.NET programs in this book are also included in this namespace. When you use these primitive types in your programs, the language you use may already have an equivalent native data type that corresponds to a .NET Framework type. Table 5-1 shows some data types and their VB.NET native language equivalents.
Table 5-1 Primitive Data Types and VB.NET Equivalents
|
NET Data Type Class Name (System Namespace) |
VB.NET Data Type |
|
Byte |
Byte |
|
SByte |
Not supported |
|
Int16 |
Short |
|
Int32 |
Integer |
|
Int64 |
Long |
|
UInt16 |
Not supported |
|
UInt32 |
Not supported |
|
UInt64 |
Not supported |
|
Single |
Single |
|
Double |
Double |
|
Object |
Object |
|
Char |
Char |
|
String |
String |
|
Decimal |
Decimal |
|
Boolean |
Boolean |
Occasionally you may want to define your own data types. You can do this by using the native features of the language with which you're working. If you're using VB.NET, you can use the Structure statement to define a structure. This custom type needs to be type-safe for the CLR, so it's no coincidence that it inherits from the ValueType .NET class.
techTalk: structures and classes
Structures and classes are quite similar. They both have members, constructors, events, properties, fields, and constants. They can both implement interfaces as well.
There are some differences. Structures don't allow for inheritance; therefore they are referred to as sealed.
Structures can't have any constructor code, that is, you can't define an overloaded New() subroutine with your own initialization code like you can with a class.
When structures are used in procedure calls, the structure is passed by value (like primitive data types are). Classes, on the other hand, are always passed by reference. Whether to use classes or structures for your user-defined data types depends mostly on the complexity of your data types. Structures are useful for defining relatively simple data types for which the members do not use much memory and no custom initialization code is required. If your design requires more than this, consider defining your custom data type as a class.
Let's quickly look at a VB.NET structure definition. Structure definitions are placed outside of procedure definitions. You can define them at the module level, as shown below.
Code Sample 5-1 Build instructions: vbc /r:system.dll cs5-01.vb
Module Module1Structure Student Dim FirstName As String Dim LastName As String Dim SSN As String Dim ClassRank As Integer End Structure Sub Main() Dim udtStudent As New Student()
With udtStudent .FirstName = "Matt" .LastName = "Crouch" .SSN = "888-88-1234" .ClassRank = 2 End With End Sub End Module
The example shows a typical structure definition. The members are enclosed in
the Structure...End Structure block that begins in line . The VB.NET With...End
With statement in line is used to save some typing. It allows you to refer to
the individual members of the structure without fully qualifying the names of
the structure members.
Since the VB.NET structures you define automatically inherit from System.ValueType, you can treat the value type as a ValueType object. As a demonstration, let's create a function that lists all the members of an arbitrary structure at runtime.
Code Sample 5-2 Build instructions: vbc /r:system.dll cs5-02.vb
Public Sub ValueTypeDemoFunction(ByVal udt As ValueType) Dim mi() As MemberInfo Dim srmMemberInfo As MemberInfo Dim typTmp As TypetypTmp = udt.GetType(udt.ToString())
mi = typTmp.GetMembers() Console.WriteLine("Value Type Information" & _ Chr(13) & Chr(10)) For Each srmMemberInfo In mi Console.WriteLine(srmMemberInfo.Name) Next End Sub
The function ValueTypeDemoFunction() takes a ValueType object as its
parameter. Thus we can pass a VB.NET structure to this function. The GetType()
function in line , which is a member of the System.Object namespace, returns a
System.Type object. We use the returned System.Type object in line to get the
member names (an array of System.Reflection.MemberInfo objects).
If we modify Code Sample 5-1 to add a call to ValueTypeDemoFunction() as shown below in boldface text, we'll obtain output similar to Figure 5-1.
)
Figure 5-1 Output of the ValueType example
Sub Main()
Dim udtStudent As New Student()
With udtStudent
.FirstName = "Matt"
.LastName = "Crouch"
.SSN = "888-88-1234"
.ClassRank = 2
End With
ValueTypeDemoFunction(udtStudent)
End Sub
5.2.2 Just-in-Time Code Compilation
Managed code cannot be executed directly by the CPU. It must be converted to native executable code before running. Just-in-time (JIT) compilation compiles MSIL code right at the moment it is needed. Optimizations exist in the JIT compiler to ensure that only code planned for execution gets compiled. The JIT compiler also performs security checks and verifies type-safety.
5.2.3 Code Assemblies
I've mentioned the topic of component-based system architectures before, and now it's time to introduce the .NET Framework concept of this idea. The component (that is, the unit of reuse) in the .NET Framework is the assembly. An assembly is a collection of files, typically .dll files and any others relating to the assembly, such as resource files. The assembly manifest contains metadata relating to version information, security attributes, and external code references. It also contains information on how the pieces in the assembly relate to each other. The assembly manifest, therefore, constructs a logical DLL around the assembly elements.
5.2.4 Application Domains
Modern software systems run applications that are isolated from the internal execution of the operating system and other programs. The reason for this is to protect the operating system from crashing if the application attempts to access memory being used by another application. Another situation that could cause a crash is an internal error in the application that causes the operating system to crash. Fortunately, all versions of Windows offer process protection to prevent this problem. Each application running under Windows has its own memory space, and memory used by other running applications is not visible from any other application.
The .NET Framework extends the capabilities of protected process spaces by building this functionality into the CLR. These protected spaces are known as application domains. In addition to the fault tolerance that process isolation provides, application domains can enforce security policies, thereby granting or denying users and groups the right to run the application. Application domains also consume fewer system resources than traditional Windows processes because they can provide fault tolerance by taking advantage of the inherit type-safety of the .NET Framework code.