Visual Studio 2008 ships with the expected GUI designers, code snippet support, database manipulation
tools, object and project browsing utilities, and an integrated help system. Unlike many of
the IDEs we have already examined, Visual Studio 2008 provides numerous additions. Here is a
partial list:
� Visual XML editors/designers
� Support for mobile device development (such as Smartphones and Pocket PC devices)
� Support for Microsoft Office development
� Designer support for Windows Workflow Foundation projects
� Integrated support for code refactoring
� Visual class design utilities
� The Object Test Bench window, which allows you to create objects and invoke their members
directly within the IDE
To be completely honest, Visual Studio 2008 provides so many features that it would take an
entire book (a rather large book at that) to fully describe every aspect of the IDE. This is not that
book. However, I do want to point out some of the major features in the pages that follow. As you
progress through the text, you�ll learn more about the Visual Studio 2008 IDE where appropriate.
Monday, 30 November 2009
over view of Common Language Runtime (CLR)
In addition to the CTS and CLS specifications, the final TLA (three-letter abbreviation) to contend
with at the moment is the CLR. Programmatically speaking, the term runtime can be understood as
a collection of external services that are required to execute a given compiled unit of code. For
example, when developers make use of the MFC to create a new application, they are aware that
their program requires the MFC runtime library (i.e., mfc42.dll). Other popular languages also
have a corresponding runtime. VB6 programmers are also tied to a runtime module or two (e.g.,
msvbvm60.dll). Java developers are tied to the Java Virtual Machine (JVM), and so forth.
The .NET platformoffers yet another runtime system. The key difference between the .NET
runtime and the various other runtimes I just mentioned is the fact that the .NET runtime provides
a single well-defined runtime layer that is shared by all languages and platforms that are .NETaware.
The crux of the CLR is physically represented by a library named mscoree.dll (a.k.a. the Common
Object Runtime Execution Engine). When an assembly is referenced for use, mscoree.dll is
loaded automatically, which in turn loads the required assembly into memory. The runtime engine
is responsible for a number of tasks. First and foremost, it is the entity in charge of resolving the
location of an assembly and finding the requested type within the binary by reading the contained
metadata. The CLR then lays out the type in memory, compiles the associated CIL into platformspecific
instructions, performs any necessary security checks, and then executes the code in
question.
In addition to loading your custom assemblies and creating your custom types, the CLR will
also interact with the types contained within the .NET base class libraries when required. Although
the entire base class library has been broken into a number of discrete assemblies, the key assembly
is mscorlib.dll. mscorlib.dll contains a large number of core types that encapsulate a wide variety
of common programming tasks as well as the core data types used by all .NET languages. When you
build .NET solutions, you automatically have access to this particular assembly.
Figure 1-4 illustrates the workflow that takes place between your source code (which is making
use of base class library types), a given .NET compiler, and the .NET execution engine.
with at the moment is the CLR. Programmatically speaking, the term runtime can be understood as
a collection of external services that are required to execute a given compiled unit of code. For
example, when developers make use of the MFC to create a new application, they are aware that
their program requires the MFC runtime library (i.e., mfc42.dll). Other popular languages also
have a corresponding runtime. VB6 programmers are also tied to a runtime module or two (e.g.,
msvbvm60.dll). Java developers are tied to the Java Virtual Machine (JVM), and so forth.
The .NET platformoffers yet another runtime system. The key difference between the .NET
runtime and the various other runtimes I just mentioned is the fact that the .NET runtime provides
a single well-defined runtime layer that is shared by all languages and platforms that are .NETaware.
The crux of the CLR is physically represented by a library named mscoree.dll (a.k.a. the Common
Object Runtime Execution Engine). When an assembly is referenced for use, mscoree.dll is
loaded automatically, which in turn loads the required assembly into memory. The runtime engine
is responsible for a number of tasks. First and foremost, it is the entity in charge of resolving the
location of an assembly and finding the requested type within the binary by reading the contained
metadata. The CLR then lays out the type in memory, compiles the associated CIL into platformspecific
instructions, performs any necessary security checks, and then executes the code in
question.
In addition to loading your custom assemblies and creating your custom types, the CLR will
also interact with the types contained within the .NET base class libraries when required. Although
the entire base class library has been broken into a number of discrete assemblies, the key assembly
is mscorlib.dll. mscorlib.dll contains a large number of core types that encapsulate a wide variety
of common programming tasks as well as the core data types used by all .NET languages. When you
build .NET solutions, you automatically have access to this particular assembly.
Figure 1-4 illustrates the workflow that takes place between your source code (which is making
use of base class library types), a given .NET compiler, and the .NET execution engine.
Over view of Common Language Specification (CLS)
As you are aware, different languages express the same programming constructs in unique, language-
specific terms. For example, in C# you denote string concatenation using the plus operator
(+), while in VB .NET you typically make use of the ampersand (&). Even when two distinct languages
express the same programmatic idiom (e.g., a function with no return value), the chances
are very good that the syntax will appear quite different on the surface:
// C# method returning nothing.
public void MyMethod()
{
// Some interesting code...
}
' VB method returning nothing.
Public Sub MyMethod()
' Some interesting code...
End Sub
As you have already seen, these minor syntactic variations are inconsequential in the eyes of
the .NET runtime, given that the respective compilers (csc.exe or vbc.exe, in this case) emit a similar
set of CIL instructions. However, languages can also differ with regard to their overall level of
functionality. For example, a .NET language may or may not have a keyword to represent unsigned
data, and may or may not support pointer types. Given these possible variations, it would be ideal
to have a baseline to which all .NET-aware languages are expected to conform.
The CLS is a set of rules that describe in vivid detail the minimal and complete set of features a
given .NET-aware compiler must support to produce code that can be hosted by the CLR, while at
the same time be accessed in a uniform manner by all languages that target the .NET platform. In
many ways, the CLS can be viewed as a subset of the full functionality defined by the CTS.
The CLS is ultimately a set of rules that compiler builders must conform to, if they intend their
products to function seamlessly within the .NET universe. Each rule is assigned a simple name (e.g.,
�CLS Rule 6�) and describes how this rule affects those who build the compilers as well as those
who (in some way) interact with them. The cr�me de la cr�me of the CLS is the mighty Rule 1:
� Rule 1: CLS rules apply only to those parts of a type that are exposed outside the defining
assembly.
Given this rule, you can (correctly) infer that the remaining rules of the CLS do not apply to the
logic used to build the inner workings of a .NET type. The only aspects of a type that must conform
to the CLS are the member definitions themselves (i.e., naming conventions, parameters, and
return types). The implementation logic for a member may use any number of non-CLS techniques,
as the outside world won�t know the difference.
To illustrate, the following Add() method is not CLS-compliant, as the parameters and return
values make use of unsigned data (which is not a requirement of the CLS):
class Calc
{
// Exposed unsigned data is not CLS compliant!
public ulong Add(ulong x, ulong y)
{ return x + y;}
}
However, if you were to simply make use of unsigned data internally as follows:
class Calc
{
public int Add(int x, int y)
{
// As this ulong variable is only used internally,
// we are still CLS compliant.
ulong temp = 0;
...
return x + y;
}
}
you have still conformed to the rules of the CLS, and can rest assured that all .NET languages are
able to invoke the Add() method.
Of course, in addition to Rule 1, the CLS defines numerous other rules. For example, the
CLS describes how a given language must represent text strings, how enumerations should be
represented internally (the base type used for storage), how to define static members, and so forth.
Luckily, you don�t have to commit these rules to memory to be a proficient .NET developer. Again,
by and large, an intimate understanding of the CTS and CLS specifications is only of interest to
tool/compiler builders.
specific terms. For example, in C# you denote string concatenation using the plus operator
(+), while in VB .NET you typically make use of the ampersand (&). Even when two distinct languages
express the same programmatic idiom (e.g., a function with no return value), the chances
are very good that the syntax will appear quite different on the surface:
// C# method returning nothing.
public void MyMethod()
{
// Some interesting code...
}
' VB method returning nothing.
Public Sub MyMethod()
' Some interesting code...
End Sub
As you have already seen, these minor syntactic variations are inconsequential in the eyes of
the .NET runtime, given that the respective compilers (csc.exe or vbc.exe, in this case) emit a similar
set of CIL instructions. However, languages can also differ with regard to their overall level of
functionality. For example, a .NET language may or may not have a keyword to represent unsigned
data, and may or may not support pointer types. Given these possible variations, it would be ideal
to have a baseline to which all .NET-aware languages are expected to conform.
The CLS is a set of rules that describe in vivid detail the minimal and complete set of features a
given .NET-aware compiler must support to produce code that can be hosted by the CLR, while at
the same time be accessed in a uniform manner by all languages that target the .NET platform. In
many ways, the CLS can be viewed as a subset of the full functionality defined by the CTS.
The CLS is ultimately a set of rules that compiler builders must conform to, if they intend their
products to function seamlessly within the .NET universe. Each rule is assigned a simple name (e.g.,
�CLS Rule 6�) and describes how this rule affects those who build the compilers as well as those
who (in some way) interact with them. The cr�me de la cr�me of the CLS is the mighty Rule 1:
� Rule 1: CLS rules apply only to those parts of a type that are exposed outside the defining
assembly.
Given this rule, you can (correctly) infer that the remaining rules of the CLS do not apply to the
logic used to build the inner workings of a .NET type. The only aspects of a type that must conform
to the CLS are the member definitions themselves (i.e., naming conventions, parameters, and
return types). The implementation logic for a member may use any number of non-CLS techniques,
as the outside world won�t know the difference.
To illustrate, the following Add() method is not CLS-compliant, as the parameters and return
values make use of unsigned data (which is not a requirement of the CLS):
class Calc
{
// Exposed unsigned data is not CLS compliant!
public ulong Add(ulong x, ulong y)
{ return x + y;}
}
However, if you were to simply make use of unsigned data internally as follows:
class Calc
{
public int Add(int x, int y)
{
// As this ulong variable is only used internally,
// we are still CLS compliant.
ulong temp = 0;
...
return x + y;
}
}
you have still conformed to the rules of the CLS, and can rest assured that all .NET languages are
able to invoke the Add() method.
Of course, in addition to Rule 1, the CLS defines numerous other rules. For example, the
CLS describes how a given language must represent text strings, how enumerations should be
represented internally (the base type used for storage), how to define static members, and so forth.
Luckily, you don�t have to commit these rules to memory to be a proficient .NET developer. Again,
by and large, an intimate understanding of the CTS and CLS specifications is only of interest to
tool/compiler builders.
Common Type System (CTS)
A given assembly may contain any number of distinct types. In the world of .NET, type is simply a
general term used to refer to a member from the set {class, interface, structure, enumeration, delegate}.
When you build solutions using a .NET-aware language, you will most likely interact with
many of these types. For example, your assembly may define a single class that implements some
number of interfaces. Perhaps one of the interface methods takes an enumeration type as an input
parameter and returns a structure to the caller.
Recall that the CTS is a formal specification that documents how types must be defined in
order to be hosted by the CLR. Typically, the only individuals who are deeply concerned with the
inner workings of the CTS are those building tools and/or compilers that target the .NET platform.
It is important, however, for all .NET programmers to learn about how to work with the five types
defined by the CTS in their language of choice. Here is a brief overview.
CTS Class Types
Every .NET-aware language supports, at the very least, the notion of a class type, which is the cornerstone
of object-oriented programming (OOP). A class may be composed of any number of
members (such as properties, methods, and events) and data points (fields). In C#, classes are
declared using the class keyword:
// A C# class type.
class Calc
{
public int Add(int x, int y)
{ return x + y; }
}
CTS Interface Types
Interfaces are nothing more than a named collection of abstract member definitions, which may be
supported (i.e., implemented) by a given class or structure. Unlike COM, .NET interfaces do not
derive a common base interface such as IUnknown. In C#, interface types are defined using the
interface keyword, for example:
// A C# interface type is usually
// declared as public, to allow types in other
// assemblies to implement their behavior.
public interface IDraw
{
void Draw();
}
On their own, interfaces are of little use. However, when a class or structure implements a given
interface in its unique way, you are able to request access to the supplied functionality using an
interface reference in a polymorphic manner.
CTS Structure Types
The concept of a structure is also formalized under the CTS. If you have a C background, you should
be pleased to know that these user-defined types (UDTs) have survived in the world of .NET (although
they behave a bit differently under the hood). Simply put, a structure can be thought of as a lightweight
class type having value-based semantics. For more details on the subtleties of structures, Typically, structures are best suited for modeling geometric and mathematical data, and
are created in C# using the struct keyword:
// A C# structure type.
struct Point
{
// Structures can contain fields.
public int xPos, yPos;
// Structures can contain parameterized constructors.
public Point(int x, int y)
{ xPos = x; yPos = y;}
// Structures may define methods.
public void Display()
{
Console.WriteLine("({0}, {1}", xPos, yPos);
}
}
CTS Enumeration Types
Enumerations are handy programming constructs that allow you to group name/value pairs. For
example, assume you are creating a video-game application that allows the player to select one of
three character categories (Wizard, Fighter, or Thief). Rather than keeping track of raw numerical
values to represent each possibility, you could build a custom enumeration using the enum keyword:
// A C# enumeration type.
enum CharacterType
{
Wizard = 100,
Fighter = 200,
Thief = 300
}
By default, the storage used to hold each item is a 32-bit integer; however, it is possible to alter
this storage slot if need be (e.g., when programming for a low-memory device such as a Pocket PC).
Also, the CTS demands that enumerated types derive from a common base class, System.Enum. this base class defines a number of interesting members that allow you to
extract, manipulate, and transform the underlying name/value pairs programmatically.
CTS Delegate Types
Delegates are the .NET equivalent of a type-safe C-style function pointer. The key difference is that a
.NET delegate is a class that derives from System.MulticastDelegate, rather than a simple pointer to
a raw memory address. In C#, delegates are declared using the delegate keyword:
// This C# delegate type can "point to" any method
// returning an integer and taking two integers as input.
delegate int BinaryOp(int x, int y);
Delegates are useful when you wish to provide a way for one entity to forward a call to another
entity, and provide the foundation for the .NET event architecture. delegates have intrinsic support for multicasting (i.e., forwarding a request to multiple
recipients) and asynchronous method invocations.
CTS Type Members
Now that you have previewed each of the types formalized by the CTS, realize that most types take
any number of members. Formally speaking, a type member is constrained by the set {constructor,
finalizer, static constructor, nested type, operator, method, property, indexer, field, read-only field,
constant, event}.
The CTS defines various �adornments� that may be associated with a given member. For example,
each member has a given visibility trait (e.g., public, private, protected, and so forth). Some
members may be declared as abstract to enforce a polymorphic behavior on derived types as well as
virtual to define a canned (but overridable) implementation. Also, most members may be configured
as static (bound at the class level) or instance (bound at the object level). The construction of
type members is examined over the course of the next several chapters.
nNote, the C# language also supports the construction of generic types and generic
members.
Intrinsic CTS Data Types
The final aspect of the CTS to be aware of for the time being is that it establishes a well-defined set
of fundamental data types. Although a given language typically has a unique keyword used to
declare an intrinsic CTS data type, all language keywords ultimately resolve to the same type
defined in an assembly named mscorlib.dll.
data types are expressed in various .NET languages.
The Intrinsic CTS Data Types
CTS Data Type VB .NET Keyword C# Keyword C++/CLI Keyword
System.Byte Byte byte unsigned char
System.SByte SByte sbyte signed char
System.Int16 Short short short
System.Int32 Integer int int or long
System.Int64 Long long __int64
System.UInt16 UShort ushort unsigned short
System.UInt32 UInteger uint unsigned int or unsigned long
System.UInt64 ULong ulong unsigned __int64
System.Single Single float Float
System.Double Double double Double
System.Object Object object Object^
System.Char Char char wchar_t
System.String String string String^
System.Decimal Decimal decimal Decimal
System.Boolean Boolean bool Bool
Given the fact that the unique keywords of a managed language are simply shorthand notations
for a real type in the System namespace, we no longer have to worry about overflow/underflow
conditions for numerical data, or how strings and Booleans are internally represented across different
languages. Consider the following code snippets, which define 32-bit numerical variables in C#
and VB .NET, using language keywords as well as the formal CTS type:
// Define some "ints" in C#.
int i = 0;
System.Int32 j = 0;
' Define some "ints" in VB .NET.
Dim i As Integer = 0
Dim j As System.Int32 = 0
general term used to refer to a member from the set {class, interface, structure, enumeration, delegate}.
When you build solutions using a .NET-aware language, you will most likely interact with
many of these types. For example, your assembly may define a single class that implements some
number of interfaces. Perhaps one of the interface methods takes an enumeration type as an input
parameter and returns a structure to the caller.
Recall that the CTS is a formal specification that documents how types must be defined in
order to be hosted by the CLR. Typically, the only individuals who are deeply concerned with the
inner workings of the CTS are those building tools and/or compilers that target the .NET platform.
It is important, however, for all .NET programmers to learn about how to work with the five types
defined by the CTS in their language of choice. Here is a brief overview.
CTS Class Types
Every .NET-aware language supports, at the very least, the notion of a class type, which is the cornerstone
of object-oriented programming (OOP). A class may be composed of any number of
members (such as properties, methods, and events) and data points (fields). In C#, classes are
declared using the class keyword:
// A C# class type.
class Calc
{
public int Add(int x, int y)
{ return x + y; }
}
CTS Interface Types
Interfaces are nothing more than a named collection of abstract member definitions, which may be
supported (i.e., implemented) by a given class or structure. Unlike COM, .NET interfaces do not
derive a common base interface such as IUnknown. In C#, interface types are defined using the
interface keyword, for example:
// A C# interface type is usually
// declared as public, to allow types in other
// assemblies to implement their behavior.
public interface IDraw
{
void Draw();
}
On their own, interfaces are of little use. However, when a class or structure implements a given
interface in its unique way, you are able to request access to the supplied functionality using an
interface reference in a polymorphic manner.
CTS Structure Types
The concept of a structure is also formalized under the CTS. If you have a C background, you should
be pleased to know that these user-defined types (UDTs) have survived in the world of .NET (although
they behave a bit differently under the hood). Simply put, a structure can be thought of as a lightweight
class type having value-based semantics. For more details on the subtleties of structures, Typically, structures are best suited for modeling geometric and mathematical data, and
are created in C# using the struct keyword:
// A C# structure type.
struct Point
{
// Structures can contain fields.
public int xPos, yPos;
// Structures can contain parameterized constructors.
public Point(int x, int y)
{ xPos = x; yPos = y;}
// Structures may define methods.
public void Display()
{
Console.WriteLine("({0}, {1}", xPos, yPos);
}
}
CTS Enumeration Types
Enumerations are handy programming constructs that allow you to group name/value pairs. For
example, assume you are creating a video-game application that allows the player to select one of
three character categories (Wizard, Fighter, or Thief). Rather than keeping track of raw numerical
values to represent each possibility, you could build a custom enumeration using the enum keyword:
// A C# enumeration type.
enum CharacterType
{
Wizard = 100,
Fighter = 200,
Thief = 300
}
By default, the storage used to hold each item is a 32-bit integer; however, it is possible to alter
this storage slot if need be (e.g., when programming for a low-memory device such as a Pocket PC).
Also, the CTS demands that enumerated types derive from a common base class, System.Enum. this base class defines a number of interesting members that allow you to
extract, manipulate, and transform the underlying name/value pairs programmatically.
CTS Delegate Types
Delegates are the .NET equivalent of a type-safe C-style function pointer. The key difference is that a
.NET delegate is a class that derives from System.MulticastDelegate, rather than a simple pointer to
a raw memory address. In C#, delegates are declared using the delegate keyword:
// This C# delegate type can "point to" any method
// returning an integer and taking two integers as input.
delegate int BinaryOp(int x, int y);
Delegates are useful when you wish to provide a way for one entity to forward a call to another
entity, and provide the foundation for the .NET event architecture. delegates have intrinsic support for multicasting (i.e., forwarding a request to multiple
recipients) and asynchronous method invocations.
CTS Type Members
Now that you have previewed each of the types formalized by the CTS, realize that most types take
any number of members. Formally speaking, a type member is constrained by the set {constructor,
finalizer, static constructor, nested type, operator, method, property, indexer, field, read-only field,
constant, event}.
The CTS defines various �adornments� that may be associated with a given member. For example,
each member has a given visibility trait (e.g., public, private, protected, and so forth). Some
members may be declared as abstract to enforce a polymorphic behavior on derived types as well as
virtual to define a canned (but overridable) implementation. Also, most members may be configured
as static (bound at the class level) or instance (bound at the object level). The construction of
type members is examined over the course of the next several chapters.
nNote, the C# language also supports the construction of generic types and generic
members.
Intrinsic CTS Data Types
The final aspect of the CTS to be aware of for the time being is that it establishes a well-defined set
of fundamental data types. Although a given language typically has a unique keyword used to
declare an intrinsic CTS data type, all language keywords ultimately resolve to the same type
defined in an assembly named mscorlib.dll.
data types are expressed in various .NET languages.
The Intrinsic CTS Data Types
CTS Data Type VB .NET Keyword C# Keyword C++/CLI Keyword
System.Byte Byte byte unsigned char
System.SByte SByte sbyte signed char
System.Int16 Short short short
System.Int32 Integer int int or long
System.Int64 Long long __int64
System.UInt16 UShort ushort unsigned short
System.UInt32 UInteger uint unsigned int or unsigned long
System.UInt64 ULong ulong unsigned __int64
System.Single Single float Float
System.Double Double double Double
System.Object Object object Object^
System.Char Char char wchar_t
System.String String string String^
System.Decimal Decimal decimal Decimal
System.Boolean Boolean bool Bool
Given the fact that the unique keywords of a managed language are simply shorthand notations
for a real type in the System namespace, we no longer have to worry about overflow/underflow
conditions for numerical data, or how strings and Booleans are internally represented across different
languages. Consider the following code snippets, which define 32-bit numerical variables in C#
and VB .NET, using language keywords as well as the formal CTS type:
// Define some "ints" in C#.
int i = 0;
System.Int32 j = 0;
' Define some "ints" in VB .NET.
Dim i As Integer = 0
Dim j As System.Int32 = 0
The Role of the Assembly Manifest
Last but not least, remember that a .NET assembly also contains metadata that describes the
assembly itself (technically termed a manifest). Among other details, the manifest documents all
external assemblies required by the current assembly to function correctly, the assembly�s version
number, copyright information, and so forth. Like type metadata, it is always the job of the compiler
to generate the assembly�s manifest. Here are some relevant details of the manifest generated
when compiling the Calc.cs code file shown earlier in this chapter (assume we instructed the compiler
to name our assembly Calc.exe):
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 2:0:0:0
}
.assembly Calc
{
.hash algorithm 0x00008004
.ver 0:0:0:0
}
.module Calc.exe
.imagebase 0x00400000
.subsystem 0x00000003
.file alignment 512
.corflags 0x00000001
16 CHAPTER 1 n THE PHILOSOPHY OF .NET
In a nutshell, this manifest documents the list of external assemblies required by Calc.exe (via
the .assembly extern directive) as well as various characteristics of the assembly itself (version
number, module name, and so on). Chapter 15 will examine the usefulness of manifest data in
much more detail.
assembly itself (technically termed a manifest). Among other details, the manifest documents all
external assemblies required by the current assembly to function correctly, the assembly�s version
number, copyright information, and so forth. Like type metadata, it is always the job of the compiler
to generate the assembly�s manifest. Here are some relevant details of the manifest generated
when compiling the Calc.cs code file shown earlier in this chapter (assume we instructed the compiler
to name our assembly Calc.exe):
.assembly extern mscorlib
{
.publickeytoken = (B7 7A 5C 56 19 34 E0 89 )
.ver 2:0:0:0
}
.assembly Calc
{
.hash algorithm 0x00008004
.ver 0:0:0:0
}
.module Calc.exe
.imagebase 0x00400000
.subsystem 0x00000003
.file alignment 512
.corflags 0x00000001
16 CHAPTER 1 n THE PHILOSOPHY OF .NET
In a nutshell, this manifest documents the list of external assemblies required by Calc.exe (via
the .assembly extern directive) as well as various characteristics of the assembly itself (version
number, module name, and so on). Chapter 15 will examine the usefulness of manifest data in
much more detail.
The Role of .NET Type Metadata
In addition to CIL instructions, a .NET assembly contains full, complete, and accurate metadata,
which describes each and every type (class, structure, enumeration, and so forth) defined in the
binary, as well as the members of each type (properties, methods, events, and so on). Thankfully, it
is always the job of the compiler (not the programmer) to emit the latest and greatest type metadata.
Because .NET metadata is so wickedly meticulous, assemblies are completely self-describing
entities.
To illustrate the format of .NET type metadata, let�s take a look at the metadata that has been
generated for the Add() method of the C# Calc class you examined previously (the metadata generated
for the VB .NET version of the Add() method is similar):
CHAPTER 1 n THE PHILOSOPHY OF .NET 15
TypeDef #2 (02000003)
-------------------------------------------------------
TypDefName: CalculatorExample.Calc (02000003)
Flags : [NotPublic] [AutoLayout] [Class]
[AnsiClass] [BeforeFieldInit] (00100001)
Extends : 01000001 [TypeRef] System.Object
Method #1 (06000003)
-------------------------------------------------------
MethodName: Add (06000003)
Flags : [Public] [HideBySig] [ReuseSlot] (00000086)
RVA : 0x00002090
ImplFlags : [IL] [Managed] (00000000)
CallCnvntn: [DEFAULT]
hasThis
ReturnType: I4
2 Arguments
Argument #1: I4
Argument #2: I4
2 Parameters
(1) ParamToken : (08000001) Name : x flags: [none] (00000000)
(2) ParamToken : (08000002) Name : y flags: [none] (00000000)
Metadata is used by numerous aspects of the .NET runtime environment, as well as by various
development tools. For example, the IntelliSense feature provided by tools such as Visual Studio
2008 is made possible by reading an assembly�s metadata at design time. Metadata is also used by
various object browsing utilities, debugging tools, and the C# compiler itself. To be sure, metadata is
the backbone of numerous .NET technologies including Windows Communication Foundation
(WCF), XML web services/the .NET remoting layer, reflection, late binding, and object serialization.
Chapter 16 will formalize the role of .NET metadata.
which describes each and every type (class, structure, enumeration, and so forth) defined in the
binary, as well as the members of each type (properties, methods, events, and so on). Thankfully, it
is always the job of the compiler (not the programmer) to emit the latest and greatest type metadata.
Because .NET metadata is so wickedly meticulous, assemblies are completely self-describing
entities.
To illustrate the format of .NET type metadata, let�s take a look at the metadata that has been
generated for the Add() method of the C# Calc class you examined previously (the metadata generated
for the VB .NET version of the Add() method is similar):
CHAPTER 1 n THE PHILOSOPHY OF .NET 15
TypeDef #2 (02000003)
-------------------------------------------------------
TypDefName: CalculatorExample.Calc (02000003)
Flags : [NotPublic] [AutoLayout] [Class]
[AnsiClass] [BeforeFieldInit] (00100001)
Extends : 01000001 [TypeRef] System.Object
Method #1 (06000003)
-------------------------------------------------------
MethodName: Add (06000003)
Flags : [Public] [HideBySig] [ReuseSlot] (00000086)
RVA : 0x00002090
ImplFlags : [IL] [Managed] (00000000)
CallCnvntn: [DEFAULT]
hasThis
ReturnType: I4
2 Arguments
Argument #1: I4
Argument #2: I4
2 Parameters
(1) ParamToken : (08000001) Name : x flags: [none] (00000000)
(2) ParamToken : (08000002) Name : y flags: [none] (00000000)
Metadata is used by numerous aspects of the .NET runtime environment, as well as by various
development tools. For example, the IntelliSense feature provided by tools such as Visual Studio
2008 is made possible by reading an assembly�s metadata at design time. Metadata is also used by
various object browsing utilities, debugging tools, and the C# compiler itself. To be sure, metadata is
the backbone of numerous .NET technologies including Windows Communication Foundation
(WCF), XML web services/the .NET remoting layer, reflection, late binding, and object serialization.
Chapter 16 will formalize the role of .NET metadata.
Common Intermediate Language
Let�s examine CIL code, type metadata, and the assembly manifest in a bit more detail. CIL is a language
that sits above any particular platform-specific instruction set. For example, the following C#
code models a trivial calculator. Don�t concern yourself with the exact syntax for now, but do notice
the format of the Add() method in the Calc class:
// Calc.cs
using System;
namespace CalculatorExample
{
// This class contains the app's entry point.
class Program
{
static void Main()
{
Calc c = new Calc();
int ans = c.Add(10, 84);
Console.WriteLine("10 + 84 is {0}.", ans);
// Wait for user to press the Enter key before shutting down.
Console.ReadLine();
}
}
// The C# calculator.
class Calc
{
public int Add(int x, int y)
{ return x + y; }
}
}
Once you compile this code file using the C# compiler (csc.exe), you end up with a single-file
*.exe assembly that contains a manifest, CIL instructions, and metadata describing each aspect of
the Calc and Program classes.
nNote Chapter 2 examines the details of compiling code using the C# compiler, as well as the use of graphical
IDEs such as Visual Studio, Visual C# Express, and SharpDevelop.
For example, if you were to open this assembly using ildasm.exe (examined a little later in this
chapter), you would find that the Add() method is represented using CIL such as the following:
.method public hidebysig instance int32 Add(int32 x,
int32 y) cil managed
{
// Code size 9 (0x9)
.maxstack 2
.locals init (int32 V_0)
IL_0000: nop
IL_0001: ldarg.1
IL_0002: ldarg.2
IL_0003: add
IL_0004: stloc.0
CHAPTER 1 n THE PHILOSOPHY OF .NET 13
IL_0005: br.s IL_0007
IL_0007: ldloc.0
IL_0008: ret
} // end of method Calc::Add
Don�t worry if you are unable to make heads or tails of the resulting CIL for this method�
Chapter 19 will describe the basics of the CIL programming language. The point to concentrate on
is that the C# compiler emits CIL, not platform-specific instructions.
Now, recall that this is true of all .NET-aware compilers. To illustrate, assume you created this
same application using Visual Basic .NET, rather than C#:
' Calc.vb
Imports System
Namespace CalculatorExample
' A VB "Module" is a class that contains only
' static members.
Module Program
Sub Main()
Dim c As New Calc
Dim ans As Integer = c.Add(10, 84)
Console.WriteLine("10 + 84 is {0}.", ans)
Console.ReadLine()
End Sub
End Module
Class Calc
Public Function Add(ByVal x As Integer, ByVal y As Integer) As Integer
Return x + y
End Function
End Class
End Namespace
If you examine the CIL for the Add() method, you find similar instructions (slightly tweaked by
the VB .NET compiler, vbc.exe):
.method public instance int32 Add(int32 x,
int32 y) cil managed
{
// Code size 8 (0x8)
.maxstack 2
.locals init (int32 V_0)
IL_0000: ldarg.1
IL_0001: ldarg.2
IL_0002: add.ovf
IL_0003: stloc.0
IL_0004: br.s IL_0006
IL_0006: ldloc.0
IL_0007: ret
} // end of method Calc::Add
that sits above any particular platform-specific instruction set. For example, the following C#
code models a trivial calculator. Don�t concern yourself with the exact syntax for now, but do notice
the format of the Add() method in the Calc class:
// Calc.cs
using System;
namespace CalculatorExample
{
// This class contains the app's entry point.
class Program
{
static void Main()
{
Calc c = new Calc();
int ans = c.Add(10, 84);
Console.WriteLine("10 + 84 is {0}.", ans);
// Wait for user to press the Enter key before shutting down.
Console.ReadLine();
}
}
// The C# calculator.
class Calc
{
public int Add(int x, int y)
{ return x + y; }
}
}
Once you compile this code file using the C# compiler (csc.exe), you end up with a single-file
*.exe assembly that contains a manifest, CIL instructions, and metadata describing each aspect of
the Calc and Program classes.
nNote Chapter 2 examines the details of compiling code using the C# compiler, as well as the use of graphical
IDEs such as Visual Studio, Visual C# Express, and SharpDevelop.
For example, if you were to open this assembly using ildasm.exe (examined a little later in this
chapter), you would find that the Add() method is represented using CIL such as the following:
.method public hidebysig instance int32 Add(int32 x,
int32 y) cil managed
{
// Code size 9 (0x9)
.maxstack 2
.locals init (int32 V_0)
IL_0000: nop
IL_0001: ldarg.1
IL_0002: ldarg.2
IL_0003: add
IL_0004: stloc.0
CHAPTER 1 n THE PHILOSOPHY OF .NET 13
IL_0005: br.s IL_0007
IL_0007: ldloc.0
IL_0008: ret
} // end of method Calc::Add
Don�t worry if you are unable to make heads or tails of the resulting CIL for this method�
Chapter 19 will describe the basics of the CIL programming language. The point to concentrate on
is that the C# compiler emits CIL, not platform-specific instructions.
Now, recall that this is true of all .NET-aware compilers. To illustrate, assume you created this
same application using Visual Basic .NET, rather than C#:
' Calc.vb
Imports System
Namespace CalculatorExample
' A VB "Module" is a class that contains only
' static members.
Module Program
Sub Main()
Dim c As New Calc
Dim ans As Integer = c.Add(10, 84)
Console.WriteLine("10 + 84 is {0}.", ans)
Console.ReadLine()
End Sub
End Module
Class Calc
Public Function Add(ByVal x As Integer, ByVal y As Integer) As Integer
Return x + y
End Function
End Class
End Namespace
If you examine the CIL for the Add() method, you find similar instructions (slightly tweaked by
the VB .NET compiler, vbc.exe):
.method public instance int32 Add(int32 x,
int32 y) cil managed
{
// Code size 8 (0x8)
.maxstack 2
.locals init (int32 V_0)
IL_0000: ldarg.1
IL_0001: ldarg.2
IL_0002: add.ovf
IL_0003: stloc.0
IL_0004: br.s IL_0006
IL_0006: ldloc.0
IL_0007: ret
} // end of method Calc::Add
Thursday, 5 November 2009
What are the different kind of parsers used in XML?
There are 2 parsers:
1) DOM (Document object model): This will interpret Complete XML document.Microsoft major concentration is DOM Parser.
2) SAX Parser (Simple Aplication programming Interface for XML): This will interpret XML document based on the event occurrence only it wont interpret complete document at a time. Sun mycrosystems major concentration is SAX Parser.What is XPath?
XPath is used to navigate through elements and attributes in an XML document.
1) DOM (Document object model): This will interpret Complete XML document.Microsoft major concentration is DOM Parser.
2) SAX Parser (Simple Aplication programming Interface for XML): This will interpret XML document based on the event occurrence only it wont interpret complete document at a time. Sun mycrosystems major concentration is SAX Parser.What is XPath?
XPath is used to navigate through elements and attributes in an XML document.
Wednesday, 4 November 2009
What is SOAP?
SOAP is an XML-based protocol for exchanging information between computers. Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the main focus of SOAP is Remote Procedure Calls (RPC) transported via HTTP. Like XML-RPC, SOAP is platform independent, and therefore enables diverse applications to communicate with one another.
Subscribe to:
Comments (Atom)