AN INTRODUCTION TO THE MICROSOFT .NET FRAMEWORK ARCHITECTURE AND TOOLS - B: AJANKOHTAISTA - AKTUELLT Supplementary materials for the crash course ...
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
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
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
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
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
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
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
The scientific directions being developed at the faculty can be represented in visual form, as a kind of our common mind map: 7
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
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
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