AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS

AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS
B: AJANKOHTAISTA - AKTUELLT




  AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK
                  ARCHITECTURE AND TOOLS


Supplementary materials for the crash course of software engineering




                        Evgueni V. Pychkine




               CENTRAL OSTROBOTHNIA POLYTECHNIC, 2004
AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS
PUBLISHER:                    Central Ostrobothnia Polytechnic
                              Ylivieska Unit,
                              Vierimaantie 7, 84100 Ylivieska, FINLAND

Technical editing and layout: Virve Antinoja

Photos:                       Evgueni V. Pychkine

Cover:                        Paula Salonen, Mika Pajala

B: Ajankohtaista – Aktuellt

ISBN 952-5107-38-8
ISSN 1239-0755

Printed:                      multiprint, Vaasa 2003
AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS
CONTENTS


1 INTRODUCTION...................................................................................................................................5
        1.1 About the Author ...............................................................................................................5
        1.2 Computer Science Faculty, St-Petersburg State Polytechnical University ...........................6
        1.3 Presenting the Course .......................................................................................................8

2 UNDERSTANDING THE .NET INITIATIVE ............................................................................................9
       2.1 Development of Programming Models and the .NET Vision Statement ...............................9
       2.2 The .NET Platform for the Web Services World ..................................................................9
       2.3 The .NET is About Many Things .......................................................................................11
       2.4 Introducing C#..................................................................................................................13

3 THE .NET FRAMEWORK ARCHITECTURE FOUNDATIONS.................................................................16
        3.1 Understanding the Managed Code....................................................................................16
        3.2 Assemblies.......................................................................................................................17
        3.3 The CLR Execution Model.................................................................................................19
        3.4 The Framework Class Library Essentials...........................................................................25

4 THE .NET LANGUAGE INTEROPERABILITY CONCEPTS ....................................................................28
        4.1 The Common Type System...............................................................................................28
        4.2 The Common Language Specification...............................................................................32

5 .NET APPLICATIONS DEVELOPMENT BY USING VISUAL STUDIO .NET...........................................34
        5.1 Hello World “Advanced” (Assemblies Revisited)................................................................34
        5.2 C# Standalone Application................................................................................................38
        5.3 Customizing user control..................................................................................................47
        5.4 Using Language Interoperability .......................................................................................49
        5.5 Building XML Web Service Component and Web Service Client Application.......................52

6 CONCLUSION ....................................................................................................................................62

REFERENCES ........................................................................................................................................63
AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS
TABLE OF FIGURES

Figure 2-1. Microsoft .NET platform for Web generation software ...........................................................................................10
Figure 2-2. The .NET Framework architecturally .....................................................................................................................12
Figure 3-1. Compiling source code into .NET managed modules.............................................................................................17
Figure 3-2. Introducing assembly concept ..............................................................................................................................18
Listing 3-1. HelloWorld Console Application C# Source Code ..................................................................................................18
Figure 3-3. The assembly internal structure viewed by ILDasm utility .....................................................................................19
Figure 3-4. CLR execution model............................................................................................................................................20
Figure 3-5. Managed code producers .....................................................................................................................................21
Figure 3-6. Unmanaged code producers.................................................................................................................................22
Table 3-1. The .NET executable codes....................................................................................................................................23
Figure 3-7. Loading the CLR ...................................................................................................................................................24
Table 3-2. Some general FCL namespaces.............................................................................................................................25
Table 3-3. Application-specific namespaces...........................................................................................................................26
Listing 3-2. The FCL types vs. language primitive types..........................................................................................................27
Figure 4-1. Usual approach to define languages .....................................................................................................................28
Figure 4-2. The CTS as the storage of core programming abstractions ...................................................................................29
Figure 4-3. The CLR/CTS types graph.....................................................................................................................................30
Table 4-1. The FCL types and corresponding primitive types ..................................................................................................31
Figure 4-4. The CTS and CLS cooperation ..............................................................................................................................32
Figure 4-5. Checking the CLS-compliance..............................................................................................................................33
Listing 5-1. Simple console based user dialogue ....................................................................................................................35
Listing 5-2. Main class of HelloWorldAdvanced.NET console application .................................................................................36
Figure 5-1. HelloWorldAdvanced assembly contents viewed with ILDasm...............................................................................37
Figure 5-2. Creating application window for Safe Multiplication 1.0 .NET application ..............................................................39
Listing 5-3. Actions associated with pushing Go button: parsing values and multiplication......................................................39
Listing 5-4. The full source code of the application “Safe Multiplication 1.0” ..........................................................................41
Figure 5-3. Safe Multiplication: Examples of execution ...........................................................................................................46
Figure 5-4. Improved textbox appearance...............................................................................................................................47
Figure 5-5. Inheritance from the standard user control ...........................................................................................................47
Listing 5-5. Creating non-standard user control that inherits to the FCL user control...............................................................48
Listing 5-6. Checked multiplication implemented as VB component........................................................................................50
Listing 5-7 The fragment of the method button1_Click() .........................................................................................................50
Figure 5-6. The solution explorer window with explored references folder: properties of the CheckedMultiplication assembly 51
Listing 5-8. Web service ASMX-file Service1.asmx .................................................................................................................53
Listing 5-9. C# source code for checked multiplication Web service component .....................................................................53
Figure 5-7. Multiplication Web Service files ............................................................................................................................55
Figure 5-8. Web service testing environment automatically generated by the Visual Studio .NET debugger browsed by the
       Internet Explorer...........................................................................................................................................................55
Listing 5-10. Using Web Service by calling proxy class method ..............................................................................................57
Listing 5-11. Printing message with full description of the server side error............................................................................58
Listing 5-12. Revised fragment of the main() function.............................................................................................................58
Figure 5-9. XML Web Service Infrastructure............................................................................................................................60
Figure 5-10. XML Web Service Infrastructure in details...........................................................................................................61
AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS
1 INTRODUCTION


1.1 About the Author
Officially
Evgueni V. Pychkine was born in 1969.
In 1992 Evgueni V. Pychkine has graduated from the St-Petersburg State Polytechnical
University (Honours Diploma) where he continues to work till now.
From 2000 he holds PhD in Computer Science and takes post of Associate Professor at
the Automation and Computer Science Dept.
As the Vice-Dean responsible for international cooperation he takes care about
organization of the working program of academic contacts between Computer Science
Faculty and Central Ostrobothnia Polytechnic.

Background
His background as a lecturer is associated with
courses of programming in C++ language, object-
oriented programming, software engineering and
some related subjects. The main area of interests of
him is the programming models development and
programming languages as subject of research, as
well as the subject of learning. He believes that it’s
very difficult to teach languages (both human and
machine), but he likes teach to learn languages.
As a visiting lecturer he has provided at COP the
introductive course of Java-programming and the crash course of software engineering
with using Microsoft .Net Framework.

Other interests
He speaks English, French and German. His interests to foreign languages are primarily
inspired by the interest to the cultures of different lands and peoples. In particular, he is
very interested in French literature, music and painting.
He plays piano and loves to compose music.

Essential works
Automation of the synthesis of multilevel circuits of
discrete information transducers on the free surplus
set of elements. Ph.D. thesis. St-Petersburg State
Polytechnical University, 2000.
Sonate No.2 pour piano avec suite d’aquarelles,
1996.
Alloquium (d’après Anselmus Cantuariensis) pour
piano, 1997.




                                             5
AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS
1.2 Computer Science Faculty, St-Petersburg State Polytechnical University
                                                                     http://www.spbstu.ru
                                                                  http://www.ftk.spbstu.ru

The Computer Science Faculty is the leading
Computer Science Department at the St Petersburg
State Polytechnical University. The educational
activity, scientific and innovative researches cover
numerous areas in Information and Computer
Technologies.

Since its foundation in 1976 this relatively young
institution rapidly became a real brand name in
field of high level and top quality computer
education.

Due to the wide range of international mobility programs with foreign educational
establishments as well as with various hi-tech enterprises and computer industry giants
such as Intel, IBM, Microsoft, Motorola, Altera, Hewlett Packard, Siemens and others
we have the possibilities not only to exchange new technologies, but also to share our
knowledge in teaching process. We are always open to further cooperation contacts that
could be interesting and profitable to all the partners.

Our professors provide high-appreciated courses in foreign high schools and
universities. On the whole about 50 professors, more than 130 associate and assistant
professors, 10 senior lecturers, 25 academic assistants are teaching inside the walls of
their alma mater. We are preparing graduates with BSc and MSc degrees, as well as
Dipl. Engineers, PhDs and Dr.Scs.

About 300 students enter the faculty each academic year. More than 1500 students are
studying simultaneously at the classes and laboratories in several departments of the
faculty, specializing in different branches of information technologies, control systems,
robotics, engineering cybernetics and hardware and software developments.

We have vast experience of organizing short-term courses in computer science
disciplines for international students. As the example of successful active projects the
the cooperation program with Central Ostrobothnia Polytechnic may be emphasized.

We are also interested in any kind of research cooperation. Among the most significant
research trends noticeable nowadays at the faculty the enterprise quality software
development, software quality metrics, software-testing methods, distributed software
development, software and hardware modeling, simulation and co-simulation systems,
software environments and technologies, single chip microcontrollers systems, hybrid
systems, cognitive and multi-agent systems, software security and reliability, wireless
telecommunication systems could be cited.




                                          6
AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS
The scientific directions being developed at the faculty can be represented in visual
form, as a kind of our common mind map:




                                         7
AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS
1.3 Presenting the Course

The purpose of this work is to explain in brief how to develop different kind of
applications for the .NET Framework and to let students have some supplementary
materials to be well prepared for the crash course lectures and practice.

Audience
The introduced course is oriented to students and IT professionals that want to learn
more about actual trends of software construction. The course provides students with
understanding of the leading concepts which software engineering technologies of the
day are based on. Students will get the skills to create applications of moderate
complexity with using Microsoft .NET platform. The students will learn the C#
essentials and get the primary understanding how the language interoperability is
supported by the .NET Framework programming model.

At Course Completion
At the end of the course, students will understand the object model and its elements,
the ways the object model is implemented in different languages and programming
technologies. The students will have the understanding of the .NET Framework
architecture and the .NET Framework programming model. After completing practical
exercises students will be able to create Web applications of moderate complexity,
including XML Web services and client applications accessing Web services.

Prerequisites
Before attending the course students must have some experience in programming with
at least one language such as C++, Java or Object Pascal; basics of procedural, object-
oriented and component programming; basics of data flows, control flows and
structural programming fundamentals; primary understanding of what is Web and
basic conception of client/server computing. The experience in using Microsoft
Windows operating systems family and Microsoft Visual Studio developer’s tools is
desired. Being familiarized with XML and related technologies is helpful, but not
required.

Acknowledgements
I’d like to thank all listeners and readers of the draft versions of this work, among them:
Juha Huumonen, the chief of international department of COP (Ylivieska unit), some
students specializing in media technologies at COP after guidance of Veikko Brax, my
students at the Computer Science Faculty of the St-Petersburg State Polytechnical
University (SPbSPU), Alexander Pavlov (completed his M.Sc. work after my guidance)
for his help in preparing some application examples dealing with Web Services, Anna
Besstrashnova for her helpful notes regarding to language usage, and, of course, my
wife Galina who is one of the first listeners and critiques of my works.
I’m especially grateful to Veikko Brax for his constant help in organizing these courses
in the framework of the cooperation between Central Ostrobothnia and St-Petersburg
Polytechnics and all necessary arrangements and preparations.




                                           8
AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS
2 UNDERSTANDING THE .NET INITIATIVE


2.1 Development of Programming Models and the .NET Vision Statement

Somewhat about 2000 Microsoft’s chiefs Bill Gates and Steve Ballmer declared that they
have had changed the company and since that time it is “no more just about personal
computers, but about empowering people through great software, any time, any place
and on any device” [Miller, 2002]. From the philosophical point of view, the .NET
platform can be understood as some implementation of this vision statement.

From more practical and more technical prospective, the .NET Framework
programming model is one of the possible answers to the actual needs of software
producers and software customers. To see this clearly let us make a brief historical look
at the development of programming models.

In over than 15-20 years we’ve known multiple different programming models that
have been mainly associated with sorts of hardware of the day. Some of these models
are still being used; some of them are rather archaic. One of the first programming
models we’ve known is mainframe-programming model, based on time and resources
sharing. With expansion of relatively cheap personal computers available for end
customers a desktop programming model appeared, firstly for so called monolithic
applications (that in general are totally separate entities), and then for shared memory
Windows-like applications. Another level of representing data exchange and resource
access abstractions was implemented by the client/server architecture (that in general is
not tightly integrated with operating systems where applications run). In some sense,
the client/server architecture oriented programming can also be distinguished as one of
the ways to program.

Then we’ve seen at least a couple of versions of the Web usage: we’ve seen so called
printing on the Web, basically just putting HTML code out on the Web-site (eventually
integrated with script code providing a client located functionality); we’ve seen a
dynamic Web-pages creation, based on the server-side solutions using e.g. ASP and
databases access.

2.2 The .NET Platform for the Web Services World
Web Generation Programming
A lot of IT-professionals and software developers really believe we’re going to a new
programming model that is often called the third generation of the Web [Risse, 2001].
Following Risse’s definition, this model is response to the users’ needs to standardize
the way to program the Web that works within the company (that is often called the
Intranet), that works outside of the company (that is usually called “business-to-
business”, B2B, or simply the Extranet) or the web that works for consumers (generally
called the Internet that provides “business-to-client” communication schema, or B2C).




                                           9
AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS
One of assumptions which this new generation Web programming model is being
derived from is that a user may want to get information from the Web by using any
device at any time: by using a cell phone or a palm, by using a simple desktop browser,
or a rich desktop, etc. The Internet is then introduced as a standard networking
environment, where the idea of delivering software as a service (not obligatorily as an
end product) is exposed. The way to create such kind of service-oriented applications is
then called Web services programming model.

Web Services
What is a Web service? From the developer’s prospective, Web service is a
programmable application component that can be called similar way you use to make a
function call, or a DLL-method call, or an API-function call. Web services are accessible
as URL-addressed resources via ubiquitous Internet protocols. As a rule, Web services
are very small reusable application components that can be shared seamlessly among
Web sites as services.
From the user prospective, Web service programming model implements the earlier
discussed idea of software as a service, software accessible when users need it. It’s
important to note that Web services programming model is not a Microsoft-centric
model. We know, for example, Java-based implementation of Web services
programming model.

The .NET Platform for the Web Generation Software
The .NET platform is then Microsoft offer to the Web services world (see Figure 2-1).
It includes aspects of mobile users support, home clients as well as the work place based
clients, accessing software components by using different kinds of devices. So, the .NET
Framework is aimed to connect devices.




Figure 2-1. Microsoft .NET platform for Web generation software




                                           10
It includes a set of experiences that around what people do: do they work on the Web at
home, or in the office, do they work on information documents, do they work as
busyness analysts or as developers. Hence, the .NET Framework is aimed to connect
user experiences, i.e. to connect people.

It includes a set of so called core services, such as Microsoft .NET Passport service that
is already well known to those who has Hotmail account. And this could be called as
“connecting information systems”.

Finally it includes server infrastructure that is aimed to provide the ability of the
services to be available 24/7 in scalable and reliable infrastructure. This server
applications also take care about integration of the Web services world with the systems
that users already have.

2.3 The .NET is About Many Things

The thing, we should touch before going further, is the understanding that the .NET is
not only about Web services. The presentation of an approach to program the Web with
Web services is surely the key strength used to mobilize developers to start learning the
.NET Framework architecture and tools (and it’s exactly what we do), and thinking this
way, it is some kind of marketing. But the .NET Framework supports all kinds of
applications. As Chappell said, “the .NET is about Web services, certainly, but it’s also
about many other things” [Chappell, 2002]. So, in the framework of this course we
should try to talk about “many other things”, not only or mainly about Web services.

The .NET Framework as a Development Platform
The kernel of the .NET Initiative is the .NET Framework as a development platform for
developing such kind of .NET applications as XML Web Services, Web Forms
applications, Win32 GUI-based applications, Win32 console applications, Windows
services and utilities. The .NET Framework can be installed on all 32-bits versions of
Windows family operating systems (Windows 98, Windows 98 SE, Windows Me,
Windows NT 4.0, Windows 2000), and on all versions of Windows XP and Windows
.NET Server Family. Windows Server 2003 ships already with Microsoft .NET
Framework 1.1.

Additionally Microsoft has developed a rich software developer’s kit (the .NET
Framework SDK) that is distributed for free and includes compilers for all .NET
languages implemented by Microsoft (C#, Visual Basic .NET, C++ with Managed
Extensions .NET, JScript .NET, J#) as well as collection of utilities and documentation
files. The .NET Framework SDK requires Windows NT 4.0, Windows 2000, Windows
XP, or Windows .NET Server family OS.

The Common Language Runtime
As to architecture, the .NET Framework is based on two foundation parts (see
Figure 2-2): the Common Language Runtime (CLR) and the Framework Class Library
(FCL).




                                           11
Figure 2-2. The .NET Framework architecturally


The Common Language Runtime is the execution environment where all .NET
applications are run. The CLR is firstly implemented for Windows family operating
systems. Distribution of CLR elements as open source will support the implementation
of the CLR for other system architectures. The essential parts of the CLR specification
together with C# language and the portions of the FCL are already standardized by the
European Computer Manufacturers Association (ECMA). All this opens doors (or
“windows”☺) for implementation of the .NET Framework on different system
platforms and architectures.

Let us briefly analyze the common reasons of using special execution environment
instead of direct source code compilation into native code executed by a processor.

The increasing of the software size and complexity, often requiring reusable code
components accessible by the Web, caused the necessity to develop programming
systems oriented to produce mobile, safe and stable code. The code mobility assumes
that it’s possible to execute the code on different platforms and architectures. The code
safety is in strong relation to the language facilities guaranteeing that the code has no
unauthorized access to the resources of the computer where the code run on. The code
stability depends in great part on possibility to detect errors as early as possible in
development time or in runtime and on total exclusion of some classes of errors (such as
memory management errors, uncaught exception errors, uninitialized objects errors,
etc.) [Pychkine, 2003-2]. The standard mechanism making able to deal with code having
such characteristics, is based on the idea of using a special execution system working
with some kind of intermediate code instead of direct compilation of a source code into
a set of processor instructions. The common language runtime is an implementation of
this idea in the .NET Framework programming architecture.



                                           12
The Framework Class Library
The Framework Class Library contains definitions of thousands .NET types used while
constructing .NET components. The FCL is also one of the most important constituent
parts of the .NET Framework. By definition, the FCL is the common base class library
available for all .NET languages. Certainly, different languages may have features that
are not directly mapped to each other. This problem is resolved by the common
language specification (CLS). CLS-compliance of a component means that this
component can produce or/and consume code originally written in other .NET
language.

The .NET Compact Framework
The light (or “lite” as Richter named [Richter, 2002]), version of .NET Framework called
the .NET Compact Framework for pocket PCs and mobile devices is also realized.

Visual Studio .NET
As a development environment the Visual Studio .NET is realized. The last chapter of
this work shows in some details how to use Visual Studio .NET tools to create different
kinds of .NET applications.

The last release of the .NET development environment is Visual Studio .NET 2003
edition that provides support development, debugging, emulation and testing
applications for portable and mobile devices among others features.

2.4 Introducing C#

Despite having a lot of languages ported to the .NET platform, for many people C# is
one of the most visible aspects of the .NET initiative. The reasons of this are the
following:
      • It expresses the .NET concepts better than other .NET languages.
      • It supports component programming at the language level.
      • It is widely used by Microsoft professionals in their presentations and
          marketing campaigns regarding the .NET Framework programming.
      • It is immediately familiar to C++ developers.
      • Many C# underlying concepts closely match to Java ones. This helps
          developers understand the genesis of C# and the ways C# use to implement
          concepts of object-oriented and component programming.

Generally said, each programming language is a tool that is a product of software
development conceptions, the tool that clothes the essential contents of the conceptions
in syntax form [Pychkine, 2003-2]. Subsequently, it is clear that from the developer’s
prospective, learning the language is the shortest way to have a good understanding of
the new programming infrastructure.

At first sight C# programs match very closely to Java ones. Just as Java, C# is strictly
object-oriented language that supports single inheritance with interfaces (and don’t
support multiple inheritance). C# has a lot of similar features (but not total equality) to
Java in thread processing and exception handling.


                                            13
C# has also a strong type system where all type casts are checked to be safe during a
compilation stage as well as in runtime. C# has documentation comments (with
embedded XML instead of using embedded HTML in Java documenting model).

By the way, Chappell believes that if Microsoft had no licensing problems for free
changing of Java, C# would probably not exist today [Chappell, 2001-1]. But now it
exists and it’s about useless to suffer about hypothetic circumstances, and no one knows
would Java .NET be better implementation of the .NET conceptions than C# is or not.

Although C# is to some extend a copy of Java (with using C++ syntax to express Java
compatible semantics), it has important features that don’t exist in Java. The good
example of such kind of features is attribute concept support, which allow developers
to control the code’s external behavior directly from within the code. Another example
is full support for value types such as primitive types and structures. Some features
existing in Java have been implemented in C# differently. For example, class names
may not correspond to the file names (although it’s often so); namespaces may be
“reopened” in other files and they don’t match to the internal structure of an assembly;
exceptions don’t have to be caught in the client code, etc. At last, in contrast to first
implementations of Java, C# is compiled language from the beginning (as well as all
other .NET languages).

Some C# features are virtual answers to possible demands of C++ developers, among
them are the following:
      • operator overloading that is really one of the habits of many C++
          programmers;
      • possibility to write code that uses pointers and direct access to the memory
          (i.e. to write unsafe code);
      • rich type system that contains structures (struct) and enumerations (enum);
      • passing function arguments by reference (also for value types);
      • flexible memory control that makes possible to have objects allocated on the
          stack;
      • syntax appearance, etc.

In addition, C# syntax wraps for features that can be programmed in other languages,
but that mainly are not directly language-implemented. The list of some of them
follows:
      • Component-based programming with properties and events;
      • Delegates as method types;
      • Indexers as custom specified operations that can be used as indexes;
      • Boxing / unboxing mechanism which allows treating value type instances as
          objects;
      • Attributes which allow attaching metadata to the source code and therefore
          extending the language.




                                         14
In his speech at the St-Petersburg Polytechnic in 2001 Chappell said that C++ is the way
to complicate things. If I have correctly understood the idea, strict explanation of this is
the following: complicating things means that data and process models built by using
C++ abstractions are often more complex than they actually could be. In this sense,
Java would be qualified as the language that simplifies things. This means that models
built by using Java abstractions are often simpler than they actually should be. C# is
probably the good compromise between C++ and Java approaches to program with
correspondence of the leading idea of the object-oriented programming allowing
developers to express the problem and the essential part of software project in terms of
the problem [Pychkine, 2003-1].




                                            15
3 THE .NET FRAMEWORK ARCHITECTURE FOUNDATIONS

We will shortly describe here two levels of the .NET Framework architecture (see
Figure 1-2), the CLR execution model and the FCL contents.

3.1 Understanding the Managed Code
Managed Code as a Concept
To understand better the way to program under the umbrella of the .NET Framework,
we should begin from the managed code concept. When we say “managed code” we
think about the code, where correctness and safety is checked at runtime (i.e. when the
execution environment manages the code’s lifetime and execution). To guarantee that
the executed code is “safe” and secure the CLR provides the following features
[Pavlov, 2002]:
       • Type safety verification;
       • Allocation and releasing memory resources management – Garbage Collector
          (GC) takes care about objects deletion;
       • Exceptions handling as the main consistent approach to errors handling;
       • Two levels of security: code level and user roles level.

The code is supposed to be type safe, if the following conditions are true:
      • A reference to a type is strictly compatible with the type being referenced;
      • Only appropriately defined operations are invoked for the object instance;
      • Identities are what they claim to be. It means that if, for example, some
          method is defined to accept 4-byte value, the CLR detects and blocks the
          operation required accessing parameters as 8-byte value.

During verification, managed code is examined for confirmation that the code accesses
memory locations and calls methods only through properly defined types. Here are
examples of such examined situations:
      • Out-of-bounds referencing;
      • Attempts to read memory that has not been primarily written;
      • Uncaught exceptions.

As a concept, an idea to verify code during execution isn’t new. At the same time, we
should remark that the .NET implementation of this idea uses some relatively new
approaches.

.NET Managed Modules
A managed module is the main output of any .NET compiler (Figure 2-1). The managed
module is the standard Windows PE file that requires the CLR to execute. Thinking so,
we can group the parts of a managed module into two sections. First section is in
relation to PE internal structure and information interpreted by the CLR and utilities
(we are leaving details for the classroom, see also [Richter, 2002]). The second section is
the most interesting for us because it is strongly related to the application source code
and to the .NET execution model.



                                          16
This section consists of two parts. First one is the intermediate language (IL) code that is
produced by the .NET language compilers and that will be later (in runtime) compiled
by the CLR JIT-compiler into native processor instructions set. The second one is the
metadata section. Metadata tables contain information about types and members
defined in the module as well as about types and members defined in the referenced
modules. Thus, metadata guarantee the verification of the IL code.

Due to the metadata, the IL code executed by the CLR can be checked for correctness of
memory usage, method arguments, type casts and branches control. The integration of
metadata with the code constitutes more productive and extensible model in
comparison with type libraries and IDL-files. Compilers don’t need any kind of header
files since all information can be received directly from modules.

IntelliSense tools in Visual Studio .NET allow developers getting hints about methods
signatures and type structures deduced from the corresponding metadata. Metadata is
also used to provide development time check of method calls. Garbage collector uses
metadata to control object lifetime. Metadata allows to have object serialization on
remote computer.




Figure 3-1. Compiling source code into .NET managed modules


As you see, metadata is used almost on every stage of the .NET Framework
development and execution process, so Gunnerson called metadata “glue” joining
together all .NET runtime elements [Gunnerson, 2000].

3.2 Assemblies

The CLR doesn’t actually work directly with managed modules, it works with
assemblies. Assembly is a set of logically grouped modules and resource files
(Figure 3-2). An assembly is defined in the .NET abstracts as a reusing, deployment,
versioning and security policy smallest unit. Depending on the situation, either .NET
language compiler, or IL assembly linker play the role of a linkage tool.

                                            17
Figure 3-2. Introducing assembly concept


Each assembly contains information about all modules of the assembly and about
referenced assemblies, therefore assemblies are self-describing (by their manifests). It
means that the CLR gets all information used in process of runtime verification directly
from the assembly, no additional information is required neither from the OS registry,
nor from the Active Directory [Richter, 2002]. This simplifies the .NET applications
deployment. As a result, since all the .NET components are types and therefore need no
registration, the installation procedure is often just copying files.

The .NET Framework SDK contains special utility called ILDasm (Intermediate
Language code DisASseMbler) which allows programmer to “explore” an assembly.
We take as an example the C# source code of the console application used in every
teaching book “Hello. World!” that can be implemented in the .NET Framework as
Listing 3-1 shows.

// HelloMain.cs
using System;

namespace HelloWorld
{
              /// 
              /// Main class of the console application printing "Hello, World!"
              /// 
              class CMain
              {
                            /// 
                            /// The main entry point for the application.
                            /// 
                            [STAThread]
                            static void Main(string[] args)
                            {
                                          Console.WriteLine( "Hello, World!" );
                            }
              }
}



Listing 3-1. HelloWorld Console Application C# Source Code




                                             18
After building the .NET managed module we can view the contents of the assembly
code by using the ILDasm utility so to get the information about internal structure of
this assembly as shown in Figure 3-3.




Figure 3-3. The assembly internal structure viewed by ILDasm utility


Here we see that an assembly always contains the manifest (in fact, it’s special file
where basically the names of the files that are the part of the assembly are stored, but
also the assembly’s attributes, version information, security information associated with
it, culture, publisher, publicly exported types description). Also we see the class and
members structure of the managed module and we may “explore” the IL-code of each
method of the class (as shown for the method main() in Figure 3-3).

As mentioned by Richter, the reason of introducing this new assembly concept is to
allow developers to decouple the logical and physical notions of reusable types
[Richter, 2002].

3.3 The CLR Execution Model

Now we are ready to discuss how the managed code is executed in the CLR
environment in details (see Figure 3-4).

To execute the method presented as a set of IL instructions, IL code must be converted
to the code that can be executed by the processor installed on the machine (as noted
above, this code is usually called native CPU code, or, shortly, native code). The
translation of the IL code into machine commands is the task of JIT compiler.




                                              19
Figure 3-4. CLR execution model



JIT Compilation Model
The process of JIT compilation (just-in-time compilation) is based on the idea of
compiling the code when it is called instead of total compilation of the code as a whole.
Because the CLR supplies a JIT compiler for each supported CPU architecture,
developers can write a set of IL instructions that can be JIT-compiled and executed on
computers with different architectures (instead of writing IL instructions developers
often use a high-level .NET language that is compiled into IL instructions by the
corresponding compiler). Of course, the code using specific operating system facilities
or calling platform-specific or native API methods can run only on the specific platform
it uses.

The reason for using JIT compilation instead of ordinary compilation takes into account
the fact that some methods or functions might never be invoked during execution.
Rather than spending time and memory to convert all the IL code into the native code,
it converts the IL as required during execution and stores the resulting native code so
that it is accessible for subsequent calls.




                                         20
At the beginning of execution, the class loader creates a stub and attaches it to each of a
type's methods when the type is loaded. When a method is initially called, JIT compiler
starts functioning and perform the following actions:
        1. Loads metadata of the assembly containing IL code of called method;
        2. Verifies and compiles the IL code into native processor instructions;
        3. Saves the native code in a dynamically allocated block of memory;
        4. Modifies the stub, replacing it by the address of the native code location in the
           memory;
        5. Jumps to the code in the allocated block.

On the subsequent calls of this method, neither the compilation, nor the verification is
no more needed, because the native code is already loaded to the memory, the JIT-
compiled method proceeds directly to the native code that was previously generated.

Some Details About Code Safety
The safe code concept should not be mixed with the managed code concept. Generally
speaking, the .NET managed code is an IL code which is verified to be safe. In MSDN
documents a type-safe code is defined as a code that accesses types only in well-
defined, allowable ways. Code that is proven during verification to be type-safe is
called verifiably type-safe code.




Figure 3-5. Managed code producers




                                            21
Visual Basic .NET, Visual C# .NET, Visual J# compilers and IL Assembler always
produce verifiably type-safe code in managed modules (Figure 2-5). But not all
languages are type-safe. Some language compilers, such as Microsoft Visual C++,
cannot generate verifiably type-safe managed code. Moreover, even Microsoft C++ with
Managed Extensions compiler generates unmanaged code by default. C++ compiler is
unique, as C++ is a kind of language that allows developers writing both managed and
unmanaged code (Figures 3-5, 3-6). This gives developers possibilities to use earlier
developed unmanaged C++ code without rewriting it in strict concordance to the CLR
requirements. Among this, using C#, C++ with Managed Extensions or IL assembly
language blocks of code, marked by the unsafe keyword, programmer can mark blocks
of code that contains operations qualified unsafe. This means, that this code can’t be
verifiably safe, because it’s not possible to guarantee type safety of such code due to the
limitations of the verification process or to the compiler limitations. In reality, this
unsafe code might have no dangerous or incorrect operations (i.e. be safe, in fact), but
it’s impossible to prove it during the CLR verification stage.




Figure 3-6. Unmanaged code producers


The Microsoft .NET Framework SDK contains PEVerify tool which helps developers
who generate IL code (such as compiler writers, script engine developers, and so on) to
determine whether their IL code with associated metadata meets type safety
requirements.




                                          22
Table 3-1 lists the summarized descriptions of different kinds of code just discussed:


Table 3-1. The .NET executable codes
     Code category                             Description                          Examples of
                                                                                       code
                                                                                     producers
  Verifiably type-safe IL based code that is created in strict concordance to      C#
  managed code         the “type safety contract” (see chapter “Managed Code       VB.NET
                       as a Concept” of this work). Managed code supplies          J#
                       the metadata required to provide runtime services such
                       as memory management, cross-language integration,
                       code access security, and automatic lifetime control of
                       objects.

  Not verifiably type-   IL based code that is created with concordance to the     C++
  safe managed code      “type safety contract”, but that can’t be proven by the   C# with
                         CLR during verification. Examples of such code are        unsafe blocks
                         the following:
                                 • code containing pointers or direct memory
                                     access,
                                 • code containing allocation resources on
                                     some external memory and manual freeing
                                     these memory blocks, etc.
                         The safety of such code is supposed to be checked by
                         other tools (e.g. PEVerify tool) that are not in direct
                         relation with the CLR verification procedure.

  Not verifiably type-   Code stored in DLLs, or in COM-components, or in          C++ without
  safe unmanaged         WinAPI based application components, or other             explicitly
  code                   external code (i.e. not IL code). This code is supposed   used pointers
                         to be created with concordance to type safety
                         requirements, but its type safety can’t be proven in
                         runtime.

  Unmanaged unsafe       Code that is created without regard to the conventions    C
  code                   and requirements of the CLR. Such code is executed        C++ with
                         by the CLR with minimal services (no garbage              pointers
                         collection, limited debugging, and so on).
                         Unmanaged code can be originally stored in DLLs, or
                         in COM-components, or in WinAPI based application
                         components that is supposed to be unsafe, i.e. not
                         checked for type safety (but that might actually be
                         safe).


By default, code that is not type-safe is only allowed to be run if it originates from the
local computer. Therefore, mobile code should be type-safe.




                                               23
Loading the CLR
One question aside may interest some .NET Framework programmers: how the CLR
starts functioning within Windows execution environment, or, more specifically, what
the process of loading the CLR executing managed assembly consists of.
In general, Windows loader recognizes this PE managed code as a usual unmanaged PE
file. As discussed earlier, at the structural level PE file can be considered as a
combination of two parts: PE header and PE contents (as Figure 3-7 demonstrates).




Figure 3-7. Loading the CLR


Into the “.text” part of the PE header the special stub function is inserted. The only
action it provides is to pass control to _CorExeMain that is realized in the “main .NET
Framework DLL” MSCorEE.dll. This DLL’s name is acronym from the “Microsoft
Component Object Runtime Execution Engine”.
The Windows loader finds the reference to this DLL in the “.idata” section of PE
Header, so this call of the _CorExeMain is justified.
The MSCorEE.dll is now loaded to the process memory. Subsequent actions are the
following:
       1. The _CorExeMain function takes care about the initialization of the CLR.
       2. It checks the CLR header and finds the IL entry point (shown as Main Entry
           at the picture).
       3. It runs JIT-compiler that compiles IL code into native code.
       4. Finally the control is passed to IL-Main as main thread.




                                        24
3.4 The Framework Class Library Essentials
The FCL as a Hierarchy of Namespaces
The FCL is organized as a factored and extensible hierarchy of namespaces that contains
type definitions. The FCL is one of the .NET products that aimed to unify application
models. It is the FCL structure and the regular approaches to use FCL types that in great
part supports the possibility to write code which uses redistributable components
implemented in different .NET languages without hard code’s complication.

Most namespaces contain general types used for any kind of application. Some of them
are listed in Table 3-2.
Table 3-2. Some general FCL namespaces
  FCL Namespace                  Description
  System                         Basic types used in every application
  System.Collections             Types providing organization and management
                                 of collections of objects, such as lists, queues,
                                 arrays, hash tables, and dictionaries
  System.Globalizaion            Support       for     internationalization   and
                                 globalization of code and resources: string
                                 compares, formatting cultural depending data
                                 (dates, times, calendar)
  System.IO                      Basic data stream access and management,
                                 including file and folder processing and
                                 memory input/output
  System.NET                     Support for network communication, including
                                 simple programming interfaces for common
                                 network protocols
  System.Runtime.InteropServices Types allowing managed code to call
                                 unmanaged code such as COM provided
                                 facilities or functions in Win32 DLLs, or other
                                 unmanaged code
  System.Reflection              Access to type metadata and dynamic creation
                                 and invocation of types
  System.Text                    Character encoding, character conversion, and
                                 string manipulation
  System.Xml                     Standards-based support for processing XML,
                                 including XML Schemas processing

Some namespaces are application-specific. This means that the functionality provided
by the definitions contained in these namespaces is required to construct in easier and
reliable way the different kind of .NET applications.




                                           25
Table 3-3 lists some application-specific FCL namespaces.
Table 3-3. Application-specific namespaces
  FCL Namespace         Description
  System.Web.Services   Support for Web server and client management,
                        communication, and design. Provides core infrastructure for
                        ASP.NET, including Web Forms support
  System.Web.UI         Classes and interfaces that allow you to create ASP.NET
                        server controls and pages that will appear in your Web
                        applications as user interface elements
  System.Windows.Forms  Rich user interface features for Windows-based applications
  System.ServiceProcess Classes that allow you to implement, install, and control
                        Windows service applications



The System Namespace Types and Primitive Types
The only namespace used in every application is System namespace containing data
types which are in general usage. These types are commonly supported by different
languages that use specific syntax to implement the data representing concepts. These
implementations may differ as listed below:
       • Implementing data that are differently represented at the binary code level by
          using the same syntax. For example, long keyword used in C# source code
          means 64-bit signed integer value in complementary binary code, while the same
          keyword in C++ source code corresponds to platform specific binary code
          (containing either 32-bit, or 64-bit value).
       • Implementing equal data representing concepts by different syntax. For
          example, to represent Boolean value bool keyword is used in C# syntax,
          while boolean keyword is used in Java syntax.
       • Implementing different concepts by the same syntax. For example, char type
          in Java is used to represent 16-bits Unicode characters, while the same
          keyword in C++ is used to represent signed 8-bits integers considered as
          ASCII table codes.
       • Some FCL types may be supported at the language level in some languages,
          and may not be supported at the language level in other languages. For
          example, Visual Basic don’t work with unsigned types, while C# does.




                                             26
The value types from the System namespace strictly correspond to declared data
representing concepts and therefore they are not platform or language specific. As
noted above, some primitive types of a language may map to the FCL types, some types
may not. C# language specification force programmers to use C# keywords in favor of
using FCL type names “as a matter of style”. In contrast to this, Richter believes that
using FCL type names is better than using language primitive type names because of
the following reasons [Richter, 2002]:
        • The earlier mentioned difference between implementation of different data
          representing concepts by the same syntax in different languages: in C# long
          map to the FCL type          System.Int64 (64-bit signed integer value in
          complementary binary code), but in other languages, long could map to the
          FCL type System.Int32 or even to System.Int16. “Someone reading source
          code in one language could easily misinterpret the code’s intention if they
          were used to programming in a different programming language”.
        • Many FCL types offer numbers of useful methods. These methods are defined
          to accept arguments or to return values of the FCL types. “As a matter of
          style” passing the arguments or assigning return values for such methods by
          using variables of primitive type looks a bit unnatural like (although it’s legal
          – see Listing 3-2):

static int Main(string[] args)
{
              // Check command line argument
              if( args.Length != 1 )
              {
                            Console.WriteLine( "Error. Command line argument needed" );
                            return 1;
              }
              // Parse argument that should be integer value
              int           argVal1 = Int32.Parse( args[0] );
                                                       // Correct, feels unnatural, because
Parse()
                                                       // returns System.Int32 value (not int
value)

             Int32         argVal2 = Int32.Parse( args[0] );
                                                      // Correct, feels good
             // ...
             return 0;
}



Listing 3-2. The FCL types vs. language primitive types


Although the Richter’s opinion sounds quite reasonable, you should be aware of the
fact that many developers have a habit to use language types instead of fully qualified
FCL types.




                                               27
4 THE .NET LANGUAGE INTEROPERABILITY CONCEPTS


The .NET Framework is a multilanguage platform, so developers can leverage their
existing skills and inherit their successful solutions, or integrate their current solutions
into the .NET application infrastructure.

Microsoft delivers some .NET languages (C#, Visual Basic .NET, J#, JScript). 3rd parties
also develop a lot of .NET compilers (Cobol, Eiffel, SML, etc.). The foundation
infrastructure for the multilanguage environment and interoperability support is
provided by the CLR, or, being more specific, by with the Common Type System
together with the Common Language Specification.

4.1 The Common Type System

The usual approach used by language designers is to define language’s semantics
(strongly related to the underlying abstractions) tied to the language syntax
(Figure 4-1). Then we call the process of source code translation as the syntax oriented
translation (when the semantics “is computed” in accordance of recognized syntax).




Figure 4-1. Usual approach to define languages


The other possibility is to define core programming abstractions without mapping them
to a particular syntax. If the abstractions are general enough, they could then be used in
different languages. In this case syntax and semantics are kept separate, that allows
different languages to be defined on the same underlying abstractions [Chappell, 2001-
2] (Figure 4-2).




                                           28
This is exactly what the Common Type System is aimed to.
The CTS defines how types are declared, used, and managed during runtime, or being
more detailed:
       • The CTS establishes a framework that enables cross-language integration,
           type safety, and high performance code execution,
       • The CTS provides an object-oriented model that supports the complete
           implementation of many programming languages,
       • The CTS defines rules that languages must follow to ensure that objects
           written in different languages can interact with each other.




Figure 4-2. The CTS as the storage of core programming abstractions


Thus, as a fundamental part of the CLR, the CTS specifies no particular syntax, but
defines a common set of types instead. This set of types can be used to define language
syntaxes (Figure 4-3). In fact, the only language that supports CTS integrally is IL
assembly language.




                                            29
You can also read
Next part ... Cancel