Module 2: Introduction to a Managed Execution Environment

Transcription

1 Module 2: Introduction to a Managed Execution Environment Contents Overview 1 Writing a.net Application 2 Compiling and Running a.net Application 11 Lab 2: Building a Simple.NET Application 29 Review 32

2 Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, address, logo, person, place or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property Microsoft Corporation. All rights reserved. Microsoft, ActiveX, BizTalk, IntelliMirror, Jscript, MSDN, MS-DOS, MSN, PowerPoint, Visual Basic, Visual C++, Visual C#, Visual Studio, Win32, Windows, Windows Media, and Window NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

3 Module 2: Introduction to a Managed Execution Environment 1 Overview To provide an overview of the module topics and objectives. This module introduces the concept of managed execution and shows you how to quickly build applications that use the Microsoft.NET Framework common language runtime environment.! Writing a.net Application! Compiling and Running a.net Application This module introduces the concept of managed execution and shows you how to quickly build applications that use the Microsoft.NET Framework common language runtime environment. A simple Hello World version of a console application illustrates most of the concepts that are introduced in this module. Because this course is an introduction to programming in the.net Framework, you should spend some time reading the.net Framework software development kit (SDK) documentation. In fact, the labs, demonstrations, and material for this module and other modules in this course are based on several tutorials in the.net Framework SDK. After completing this module, you will be able to:! Create simple console applications in C#.! Explain how code is compiled and executed in a managed execution environment.! Explain the concept of garbage collection.

4 2 Module 2: Introduction to a Managed Execution Environment " Writing a.net Application To introduce the topics in the section. Because all supported languages use the Common Type System and the.net Framework class library, and run in the common language runtime, programs in the supported languages are similar.! Using a Namespace! Defining a Namespace and a Class! Entry Points, Scope, and Declarations! Console Input and Output! Case Sensitivity Because all supported languages use the Common Type System and the.net Framework base class library, and run in the common language runtime, programs in the supported languages are similar. The most significant difference in programming with the supported languages is syntax. Delivery Tip Stress the importance of understanding the process of compiling and running the.net applications. Using Visual Studio.NET at this time may obscure the underlying processes. Note In this module, and in Modules 3 and 4, Notepad is used as the source code editor, instead of the Microsoft Visual Studio.NET development environment. The examples in these modules are simple enough to be compiled and built directly from a command prompt window. Working in Notepad will allow you to focus on the compilation and execution processes.

5 Module 2: Introduction to a Managed Execution Environment 3 Demonstration: Hello World To demonstrate how to build a simple application in C#. In this demonstration, you will learn how to build a simple application in C#. In this demonstration, you will learn how to build a simple application in C#. Delivery Tip As this is a short, simple demonstration, you may want to let students try it themselves.! To create the source code in C# 1. Open Notepad and type the following code: // Allow easy reference to System namespace classes using System; // Create class to hold program entry point class MainApp { public static void Main() { // Write text to the console Console.WriteLine( Hello World using C#! ); } } 2. Save the file as HelloDemoCS.cs

6 4 Module 2: Introduction to a Managed Execution Environment! To compile the source code and build an executable program Important To use Visual Studio.NET tools within a command prompt window, the command prompt window must have the proper environment settings. The Visual Studio.NET Command Prompt window provides such an environment. To run a Visual Studio.NET Command Prompt window, click Start, All Programs, Microsoft Visual Studio.NET, Visual Studio.NET Tools, and Visual Studio.NET Command Prompt. From a Visual Studio.NET Command Prompt window, type the following syntax: csc HelloDemoCS.cs Running the resulting executable will generate the following output: Hello World using C#!

7 Module 2: Introduction to a Managed Execution Environment 5 Using a Namespace To describe how to use namespaces in the.net Framework. You can fully reference classes in which an instance of System.IO.FileStream is declared by using C#:! Classes Can Be Fully Referenced // // declares a FileStream object System.IO.FileStream afilestream;! Or the Namespace of a Class Can Be Referenced # No need to fully qualify contained class names using System.IO; FileStream afilestream; You can fully reference classes, as in the following example, in which an instance of System.IO.FileStream is declared by using C#: System.IO.Filestream afilestream; However, it is more convenient to reference the required namespaces in your program. Using the namespace effectively disposes of the need to qualify all class library references, as in the following example: using System.IO;... FileStream afilestream; For example, in order to have convenient access to System objects, you must use the System namespace.

8 6 Module 2: Introduction to a Managed Execution Environment Defining a Namespace and a Class To describe how to define namespaces and classes in C#. C# supports the creation of custom namespaces and classes within those namespaces.! C# Supports Creation of Custom Namespaces and Classes Within Those Namespaces namespace CompCS { public class StringComponent { } } C# supports the creation of custom namespaces and classes within those namespaces. Tip The following is the general rule for naming namespaces: CompanyName.TechnologyName For example: Microsoft.Office This is merely a guideline. Third-party companies can choose other names. Namespaces in C# In C#, you use the namespace statement to define a new namespace, which encapsulates the classes that you create, as in the following example: namespace CompCS { public class StringComponent {... } } Note that a namespace may be nested in other namespaces, and a single namespace may be defined in multiple files. A single source code file may also define multiple namespaces.

9 Module 2: Introduction to a Managed Execution Environment 7 Entry Points, Scope, and Declarations To describe how to create program entry points in C#. Every executable program must contain an external entry point, where the application begins its execution.! In C#, the External Entry Point for a Program Is in a Class class MainApp { public static void Main() {. {...}.} }! C# Supports the Use of a Period As a Scope Resolution Operator Console.WriteLine ("First String");! In C#, Objects Must Be Declared Before They Can Be Used and Are Instantiated Using the New Keyword Lib.Comp mycomp = new new Lib.Comp(); Every executable program must contain an external entry point, where the application begins its execution. In C#, all code must be contained in methods of a class. Entry Points in C# To accommodate the entry point code in C#, you must first specify the class, as in the following example: class MainApp {...} Next, you specify the entry point for your program. The compiler requires this entry point to be a public static method called Main, as in the following example: public static void Main () {...} Scope C# uses the period as a scope resolution operator. For example, you use the syntax Console.WriteLine when referencing the WriteLine method of the Console object. Declaring and Instantiating Variables In C#, you must declare a variable before it can be used. To instantiate the object, use the new keyword. The following example in C# shows how to declare an object of type Comp, in namespace Lib, with the name mycomp: Lib.Comp mycomp = new Lib.Comp();

10 8 Module 2: Introduction to a Managed Execution Environment Console Input and Output To describe how to use Console class methods in C#. You can use the runtime Console class of the System namespace for input and output to the console of any string or numeric value by using the Read, ReadLine, Write, and WriteLine methods.! Console Class Methods # Read, ReadLine, Write, and WriteLine Console.WriteLine("Hello World using C#!"); You can use the common language runtime Console class of the System namespace for input and output to the console of any string or numeric value by using the Read, ReadLine, Write, and WriteLine methods. The following example shows a C# program that outputs a string to the console: using System; class MainApp { public static void Main() { } // Write text to the console Console.WriteLine( Hello World using C#! ); }

11 Module 2: Introduction to a Managed Execution Environment 9 Case Sensitivity To describe case sensitivity issues in programming languages. C++ and C# are casesensitive, but Visual Basic is not case-sensitive.! Do Not Use Names That Require Case Sensitivity # Components should be fully usable from both casesensitive and case-insensitive languages # Case should not be used to distinguish between identifiers within a single name scope! Avoid the Following class customer {...} class Customer {...} void foo(int X, X, int int x) x) Microsoft Visual C++ and C# are case-sensitive, but Microsoft Visual Basic is not case-sensitive. To ensure that a program is compliant with the Common Language Specification (CLS), however, you must take special care with public names. You cannot use case to distinguish between identifiers within a single name scope, such as types within assemblies and members within types. The following examples show situations to avoid:! Do not have two classes or namespaces whose names differ only by case. class customer {... } class Customer {... }! Do not have a function with two parameters whose names differ only by case. void foo(int X, int x) This constraint enables Visual Basic (and potentially other case-insensitive languages) to produce and use components that have been created in other casesensitive languages. This constraint does not apply to your definitions of private classes, private methods on public classes, or local variables.

12 10 Module 2: Introduction to a Managed Execution Environment Note To fully interact with other objects regardless of the language they were implemented in, objects must expose to callers only those features that are common to all the languages they must interoperate with. For this reason, a set of language features has been defined, called the Common Language Specification (CLS), which includes common language features that are needed by many applications. The CLS rules define a subset of the common type system; that is, all the rules that apply to the common type system apply to the CLS, except where stricter rules are defined in the CLS. If your component uses only CLS features in the API that it exposes to other code (including derived classes), the component is guaranteed to be accessible from any programming language that supports the CLS. Components that adhere to the CLS rules and use only the features included in the CLS are said to be CLS-compliant components.

13 Module 2: Introduction to a Managed Execution Environment 11 " Compiling and Running a.net Application To introduce the topics in the section. Most aspects of programming in the.net Framework are the same for all compatible languages; each supported language compiler produces selfdescribing, managed Microsoft intermediate language (MSIL) code.! Compiler Options! The Process of Managed Execution! Metadata! Microsoft Intermediate Language! Assemblies! Common Language Runtime Tools! Just-In-Time Compilation! Application Domains! Garbage Collection Delivery Tip Emphasize that you are primarily introducing new concepts and terminology. Be prepared to postpone answering questions that pertain to later modules. Encourage students to start reading the.net Framework SDK documentation. Most aspects of programming in the.net Framework are the same for all compatible languages; each supported language compiler produces selfdescribing, managed Microsoft intermediate language (MSIL) code. All managed code runs using the common language runtime, which provides cross-language integration, automatic memory management, cross-language exception handling, enhanced security, and a consistent and simplified programming model. This section introduces basic concepts of a managed execution environment and presents new terminology. Many of these concepts are covered in greater detail in subsequent modules in this course, in subsequent courses, and in the.net Framework SDK documentation. Key Points String literals in an application are stored and transported as clear text. Therefore, you should avoid putting sensitive information such as passwords in string literals.

14 12 Module 2: Introduction to a Managed Execution Environment Compiler Options To introduce compiler options in C#. The.NET Framework includes a command line compiler for C#.! Compile Directly from a Command Prompt Window! Use /t to indicate target >csc HelloDemoCS.cs >csc /t:exe HelloDemoCS.cs! Use /reference to reference assemblies >csc /t:exe /reference:assemb1.dll HelloDemoCS.cs The.NET Framework includes a command line compiler for C#. The file name of the compiler is Csc.exe. Compiling in C# To compile the source code for the Hello World application presented in the Hello World demonstration at the beginning of this module, type the following: csc HelloDemoCS.cs This syntax invokes the C# compiler. In this example, you only need to specify the name of the file to be compiled. The compiler generates the program executable, HelloDemoCS.exe.

15 Module 2: Introduction to a Managed Execution Environment 13 Command Line Options In C#, you can obtain the complete list of command line options by using the /? switch as follows: csc /? Common options include the /out switch, which specifies the name of the output file, and the /target switch, which specifies the target type. By default, the name of the output file is the name of the input file with an.exe extension. The default for the target type is an executable program. The following example shows the use of both the /out and /t switches in C#: csc /out:hellodemocs.exe /t:exe HelloDemoCS.cs The /t switch is equivalent to the /target switch. For more information about compiler options, see the.net Framework SDK documentation. Using the /reference Compilation Option When referring to other assemblies, you must use the /reference compilation switch. The /reference compilation option allows the compiler to make information in the specified libraries available to the source that is currently being compiled. The following example shows how to build an executable program from the command line by using the /reference compilation option. csc /r:assemb1.dll,assemb2.dll /out:output.exe input.cs The /r switch is equivalent to the /reference compilation switch.

16 14 Module 2: Introduction to a Managed Execution Environment The Process of Managed Execution To introduce fundamental concepts of compiling and executing code in a managed execution environment. In the.net Framework, the common language runtime provides the infrastructure for a managed execution environment. Class Libraries (MSIL and metadata) Trusted, pre-jited code only Class Loader JIT Compiler with optional verification Managed Native Code EXE/DLL (MSIL and metadata) Call to an uncompiled method Compiler Source Code Execution Security Checks Runtime Engine In the.net Framework, the common language runtime provides the infrastructure for a managed execution environment. This topic introduces fundamental concepts of compiling and executing code in a managed execution environment and identifies new terminology. Compiling Source Code When you develop an application in the.net Framework, you can write the source code in any programming language as long as the compiler that you use to compile the code targets the common language runtime. Compilation of the source code produces a managed module. The managed module is contained within a physical file also known as a portable executable (PE) file. The file may contain the following items:! Microsoft Intermediate Language (MSIL) The compiler translates the source code into MSIL, a CPU-independent set of instructions that can be efficiently converted to native code.! Type Metadata This information fully describes types, members, and other references, and is used by the common language runtime at run time.! A Set of Resources For example,.bmp or.jpg files.

17 Module 2: Introduction to a Managed Execution Environment 15 If the C# compiler s target option is either exe or library, then the compiler produces a managed module that is an assembly. Assemblies are a fundamental part of programming with the.net Framework. Assemblies are the fundamental units of sharing, deployment, security, and versioning in the common language runtime. The.NET common language runtime only executes MSIL code that is contained in an assembly. If the C# compiler s target option is module, then the compiler produces a managed module that is not an assembly, it does not contain a manifest and cannot be executed by the common language runtime. A managed module can be added to an assembly by the C# compiler, or by using the.net s Assembly Generation Tool, Al.exe. Subsequent topics in this module cover MSIL, metadata, and assemblies in more detail. Executing Code When a user executes a managed application, the operating system loader loads the common language runtime, which then begins executing the module s managed MSIL code. Because current host CPUs cannot execute the MSIL instructions directly, the common language runtime must first convert the MSIL instructions into native code. The common language runtime does not convert all of the module s MSIL code into CPU instructions at load time. Instead, it converts the instructions when functions are called. The MSIL is compiled only when needed. The component of the common language runtime that performs this function is called the justin-time (JIT) compiler. JIT compilation conserves memory and saves time during application initialization. For more information about the JIT compiler, see Just-In-Time Compilation in this module. Application Domain Operating systems and runtime environments typically provide some form of isolation between applications. This isolation is necessary to ensure that code running in one application cannot adversely affect other, unrelated applications. Application domains provide a secure and versatile unit of processing that the common language runtime can use to provide isolation between applications. Application domains are typically created by runtime hosts, which are responsible for bootstrapping the common language runtime before an application is run.

18 16 Module 2: Introduction to a Managed Execution Environment Metadata To explain how metadata is used in the common language runtime. Every compiler that targets the common language runtime is required to emit full metadata into every managed module.! Declarative Information Emitted at Compile Time! Included with All.NET Framework Files and Assemblies! Metadata Allows the Runtime to: # Load and locate code # Enforce code security # Generate native code at runtime # Provide reflection Every compiler that targets the common language runtime is required to emit full metadata into every managed module. This topic explains how the common language runtime uses metadata. Definition of Metadata Metadata is a set of data tables, which fully describe every element that is defined in a module. This information can include data types and members with their declarations and implementations, and references to other types and members. Metadata provides the common language runtime with all the information that is required for software component interaction. It replaces older technologies, such as Interface Definition Language (IDL) files, type libraries, and external registration. Metadata is always embedded in the.exe or.dll file containing the MSIL code. Therefore, it is impossible to separate metadata from the MSIL code.

19 Module 2: Introduction to a Managed Execution Environment 17 Uses for Metadata Metadata has many uses, but the following uses are most important:! Locating and loading classes Because metadata and MSIL are included in the same file, all type information in that file is available to the common language runtime at compile time. There is no need for header files because all types in a particular assembly are described by the assembly s manifest.! Enforcing security The metadata may or may not contain the permissions required for the code to run. The security system uses permissions to prevent code from accessing resources that it does not have authority to access. Other uses for metadata include:! Resolving method calls.! Setting up runtime context boundaries.! Providing reflection capability. For more information about metadata, see Metadata and Self-Describing Components in the.net Framework SDK documentation. For more information about verification of type safety, see Module 4, Deployment and Versioning, in Course 2349B, Programming with the Microsoft.NET Framework (Microsoft Visual C#.NET).

20 18 Module 2: Introduction to a Managed Execution Environment Microsoft Intermediate Language To introduce MSIL and JIT compilation. Microsoft intermediate language, sometimes called managed code, is the set of instructions that the compiler produces as it compiles source code.! Produced by Each Supported Language Compiler! Converted to Native Language by the Common Language Runtime's JIT Compilers Microsoft intermediate language (MSIL), sometimes called managed code, is the set of instructions that the compiler produces as it compiles source code. This topic explains MSIL and the general process for converting MSIL to native code. Compiled MSIL Regardless of their logical arrangement, most assemblies contain code in the form of MSIL. MSIL is a CPU-independent machine language created by Microsoft in consultation with third-party compiler vendors. However, MSIL is a much higher-level language than most CPU machine languages. MSIL contains instructions for many common operations, including instructions for creating and initializing objects, and for calling methods on objects. In addition, it includes instructions for arithmetic and logical operations, control flow, direct memory access, and exception handling. Conversion to Native Code Before MSIL code can be executed, it must be converted to CPU-specific or native code by a JIT compiler. The common language runtime provides an architecture-specific JIT compiler for each CPU architecture. These architecture-specific JIT compilers allow you to write managed code that can be JIT compiled and executed on any supported architecture. Note Any managed code that calls platform-specific native APIs or libraries can only run on a specific operating system. For more information about MSIL, see the.net Framework SDK documentation.

21 Module 2: Introduction to a Managed Execution Environment 19 Assemblies This topic introduces the concept of an assembly and the role of the assembly manifest. Managed Module (MSIL and Metadata) Managed Module (MSIL and Metadata) Assembly The common language runtime uses an assembly as the functional unit of sharing and reuse..html.gif Resource Files Multiple Managed Modules and Resource Files Are Compiled to Produce an Assembly Manifest The common language runtime uses an assembly as the functional unit of sharing and reuse. Definition of an Assembly An assembly is a unit of class deployment, analogous to a logical.dll. Each assembly consists of all the physical files that make up the functional unit: any managed modules, and resource or data files. Conceptually, assemblies provide a way to consider a group of files as a single entity. You must use assemblies to build an application, but you can choose how to package those assemblies for deployment. An assembly provides the common language runtime with the information that it needs to understand types and their implementations. As such, an assembly is used to locate and bind to referenced types at run time.

22 20 Module 2: Introduction to a Managed Execution Environment The Assembly Manifest An assembly contains a block of data known as a manifest, which is a table in which each entry is the name of a file that is part of the assembly. The manifest includes the metadata that is needed to specify the version requirements, security identity, and the information that is used to define the scope of the assembly and resolve references to resources and classes. Because the metadata makes an assembly self-describing, the common language runtime has the information it requires for each assembly to execute. All applications that are executed by the common language runtime must be composed of an assembly or assemblies. All files that make up an assembly must be listed in the assembly s manifest. The manifest can be stored in singlefile assemblies or multi-file assemblies:! Single-file assemblies When an assembly has only one associated file, the manifest is integrated into a single PE file.! Multi-file assemblies When an assembly has more than one associated file, the manifest can be a standalone file, or it can be incorporated into one of the PE files in the assembly. For more information about assemblies, see Assemblies in the.net Framework SDK documentation.

23 Module 2: Introduction to a Managed Execution Environment 21 Common Language Runtime Tools This topic describes how the MSIL Assembler and MSIL Disassembler work. The common language runtime provides two tools that you can use together to test and debug MSIL code.! Runtime Utilities for Working with MSIL # MSIL Assembler (ilasm.exe) produces a final executable binary # MSIL Disassembler (ildasm.exe) inspects metadata and code of a managed binary The common language runtime provides two tools that you can use to test and debug MSIL code.! The MSIL Assembler The MSIL Assembler (Ilasm.exe) takes MSIL as text input and generates a PE file, which contains the binary representation of the MSIL code and required metadata. The basic syntax is as follows: ilasm [options] filename [options]! The MSIL Disassembler You can use the MSIL Disassembler (Ildasm.exe) to examine the metadata and disassembled code of any managed module. You will use this tool to examine MSIL code in Lab 2, Building a Simple.NET Application.

24 22 Module 2: Introduction to a Managed Execution Environment Demonstration: Using the MSIL Disassembler To demonstrate how the MSIL Disassembler works. This demonstration shows how to use the MSIL Disassembler to view an assembly s metadata. This demonstration shows how to use the MSIL Disassembler to view an assembly s metadata. Viewing Assembly Metadata by Using the MSIL Disassembler In the following procedures, you will see how to use the MSIL Disassembler (Ildasm.exe) to view the contents of the HelloDemoCS.exe assembly.! To run the MSIL Disassembler on the HelloDemoCS.exe assembly At a Visual Studio.NET Command Prompt window, change the directory to <install folder>\democode\mod02 where the sample file HelloDemoCS.exe has been copied, and type the following command: ildasm HelloDemoCS.exe

25 Module 2: Introduction to a Managed Execution Environment 23 After you expand the MainApp icon, the MSIL Disassembler graphical user interface (GUI) displays information about the file HelloDemoCS.exe, as shown in the following illustration:! To display the contents of the manifest 1. Double-click MANIFEST. The MANIFEST window appears, as follows: 2. Close the Manifest window, and then close ILDASM.

26 24 Module 2: Introduction to a Managed Execution Environment Just-In-Time Compilation To describe JIT compilation and introduce JIT compiler options. MSIL code must be converted into native code before it can execute. Because an intermediate step is involved, the common language runtime optimizes the compilation process for efficiency.! Process for Code Execution # MSIL converted to native code as needed # Resulting native code stored for subsequent calls # JIT compiler supplies the CPU-specific conversion As previously stated in this module, MSIL code must be converted into native code before it can execute. Because an intermediate step is involved, the common language runtime optimizes the compilation process for efficiency. The Code Execution Process The common language runtime compiles MSIL as needed. This just-in-time, or JIT, compiling saves time and memory. The basic process is as follows: 1. When the common language runtime loads a class type, it attaches stub code to each method. 2. For subsequent method calls, the stub directs program execution to the common language runtime component that is responsible for compiling a method s MSIL into native code. This component of the common language runtime is frequently referred to as the JIT compiler. 3. The JIT compiler compiles the MSIL and the method s stub is substituted with the address of the compiled code. Future calls to that method will not involve the JIT compiler because the compiled native code will simply execute.

27 Module 2: Introduction to a Managed Execution Environment 25 Application Domains To describe how application domains provide application isolation. Historically, process boundaries have been used to isolate applications running on the same computer.! Historically, Process Boundaries Used to Isolate Applications! In the Common Language Runtime, Application Domains Provide Isolation Between Applications # The ability to verify code as type-safe enables isolation at a much lower performance cost # Several application domains can run in a single process! Faults in One Application Cannot Affect Other Applications Historically, process boundaries have been used to isolate applications running on the same computer. Each application is loaded into a separate process, which isolates the application from other applications running on the same computer. The applications are isolated because memory addresses are process-relative; a memory pointer passed from one process to another cannot be used in any meaningful way in the target process. In addition, you cannot make direct calls between two processes. Instead, you must use proxies, which provide a level of indirection. Managed code must be passed through a verification process before it can be run (unless the administrator has granted permission to skip the verification). The verification process determines whether the code can attempt to access invalid memory addresses or perform some other action that could cause the process in which it is running to fail to operate properly. Code that passes the verification test is said to be type-safe. The ability to verify code as type-safe enables the common language runtime to provide as great a level of isolation as the process boundary, at a much lower performance cost. Application domains provide a secure and versatile unit of processing that the common language runtime can use to provide isolation between applications. You can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes. The ability to run multiple applications within a single process dramatically increases server scalability.

28 26 Module 2: Introduction to a Managed Execution Environment Isolating applications is also important for application security. For example, you can run controls from several Web applications in a single browser process in such a way that the controls cannot access each other's data and resources. The isolation provided by application domains has the following benefits:! Faults in one application cannot affect other applications. Because type-safe code cannot cause memory faults, using application domains ensures that code running in one domain cannot affect other applications in the process.! Individual applications can be stopped without stopping the entire process. Using application domains enables you to unload the code running in a single application. Note You cannot unload individual assemblies or types. Only a complete domain can be unloaded. Code running in one application cannot directly access code or resources from another application. The common language runtime enforces this isolation by preventing direct calls between objects in different application domains. Objects that pass between domains are either copied or accessed by proxy. If the object is copied, the call to the object is local. That is, both the caller and the object being referenced are in the same application domain. If the object is accessed through a proxy, the call to the object is remote. In this case, the caller and the object being referenced are in different application domains. Crossdomain calls use the same remote call infrastructure as calls between two processes or between two computers.

29 Module 2: Introduction to a Managed Execution Environment 27 Multimedia: Application Loading and Single-File Assembly Execution To describe how assembly code is executed. In this demonstration, you will see how a single-file private assembly is loaded and executed. Delivery Tip To start the animation, click the button in the lower-left corner of the slide. The animation plays automatically. To pause or rewind the animation, click the controls in the lower-left of the screen. Applications that are implemented by using MSIL code require the common language runtime to be installed on the user s computer in order to run. The common language runtime manages the execution of code. For example, when an application that is implemented as a single-file private assembly is run, the following tasks are performed:! The Microsoft Windows loader loads the PE file. The PE file contains a call to a function found in the file MSCorEE.dll.! Windows loads the file MSCorEE.dll and transfers control to it to initialize the common language runtime.! The common language runtime parses the metadata of the application assembly, and then the JIT compiler compiles the code.! The common language runtime then locates the PE file s managed entrypoint (the Main method in the case of a C# program), and transfers control to this entry point. If the application calls a private assembly:! The common language runtime uses probing to locate the referenced assembly, beginning in the application s root directory and then traversing the subfolders until the assembly is located. If the assembly is not found, a TypeLoadException error occurs. If the assembly is found, it is loaded by the common language runtime. The common language runtime loader parses the manifest in the referenced assembly. The JIT compiler then compiles the required code in the assembly and passes control to the called function.

30 28 Module 2: Introduction to a Managed Execution Environment Garbage Collection To introduce memory and resource management in the.net Framework. Every program uses resources, such as files, screen space, network connections, and database resources.! Garbage Collection Provides Automatic Object Memory Management in the.net Framework! You No Longer Need to Track and Free Object Memory This topic introduces memory management in the.net Framework. For more information about memory and resource management, see Module 9, Memory and Resource Management, in Course 2349B, Programming with the Microsoft.NET Framework (Microsoft Visual C#.NET). Current Memory Management Model When you create an object programmatically, you generally follow these steps: 1. Allocate memory for the object 2. Initialize the memory 3. Use the object 4. Perform cleanup on the object 5. Free the object s memory If you forget to free memory when it is no longer required or try to use memory after it has been freed, you can generate programming errors. The tracking and correction of such errors are complicated tasks because the consequences of the errors are unpredictable. Memory Management in the.net Framework The common language runtime uses a heap called the managed heap to allocate memory for all objects. This managed heap is similar to a C-Runtime heap, however you never free objects from the managed heap. In the common language runtime, garbage collection is used to manage memory deallocation. The garbage collection process frees objects when they are no longer needed by the application. For more information about garbage collection, see Module 9, Memory and Resource Management, in Course 2349B, Programming with the Microsoft.NET Framework (Microsoft Visual C#.NET).

31 Module 2: Introduction to a Managed Execution Environment 29 Lab 2: Building a Simple.NET Application To introduce the lab. In this lab, you will learn how to write, compile, and run a simple application in C# and how to use the MSIL Disassembler to examine an assembly. Objectives After completing this lab, you will be able to:! Write, compile, and run a simple application in C#.! Use the MSIL Disassembler to examine an assembly. Lab Setup Only solution files are associated with this lab. The solution files for this lab are in the folder <install folder>\labs\lab02\solution. Estimated time to complete this lab: 20 minutes

32 30 Module 2: Introduction to a Managed Execution Environment Exercise 1 Creating the Program in C# In this exercise, you will create the source code for a small console application that takes user input and writes a string to the console by using C#. The lab uses the classic Hello World application to allow you to focus on basic concepts in a managed execution environment. To help you concentrate on the syntactical aspects of this lab, you will use Notepad to create and edit the source files. From a command prompt window, you will then compile the application and test the resulting executable program.! Write the source code 1. Open Notepad and create a class in C# called MainApp. 2. Import the System namespace. 3. Define the program entry point. The entry point takes no arguments and does not return a value. 4. Create methods that accomplish the following: a. Print the following text to the console: Type your name and press Enter. b. Read in the resulting user input. c. Print the text Hello and append to the text the value that was read in. 5. Save the file as HelloLabCS.cs in the <install folder>\labs\lab02 folder.! Build and test the program Important To use Microsoft Visual Studio.NET tools within a command prompt window, the command prompt window must have the proper environment settings. The Visual Studio.NET Command Prompt window provides such an environment. To run a Visual Studio.NET Command Prompt window, click Start, All Programs, Microsoft Visual Studio.NET, Visual Studio.NET Tools, and Visual Studio.NET Command Prompt. 1. From a Visual Studio.NET Command Prompt window, type the syntax to build an executable program from HelloLabCS.cs. 2. Run the resulting executable program. Your C# program should generate the following output: Type your name and press Enter When you press ENTER, the program outputs the text Hello and whatever text you typed as input.

33 Module 2: Introduction to a Managed Execution Environment 31 Exercise 2 Using the MSIL Disassembler In this exercise, you will use the MSIL Disassembler to open a single assembly and familiarize yourself with the assembly manifest. In subsequent labs, you will explore assemblies in greater detail.! Examine the metadata for the Hello World applications 1. Open a Visual Studio.NET Command Prompt window. 2. From the Visual Studio.NET Command Prompt window, type: >ildasm /source 3. Open HelloLabCS.exe and double-click Manifest. 4. Note the following: a. The externally referenced library named mscorlib b. The assembly name HelloLabCS c. Version information (for the HelloLabCS assembly and mscorlib) 5. Close the Manifest window, double-click MainApp, double-click Main, and view the MSIL and source code.

34 32 Module 2: Introduction to a Managed Execution Environment Review To reinforce module objectives by reviewing key points. The review questions cover some of the key concepts taught in the module.! Writing a.net Application! Compiling and Running a.net Application 1. Name the root namespace for types in the.net Framework. The System namespace is the root namespace for types in the.net Framework. 2. What class and methods can your application use to input and output to the console? You can use the common language runtime s Console class of the System namespace for input and output to the console of any string or numeric value by using the Read, ReadLine, Write, and WriteLine methods. 3. When compiling code that makes references to classes in assemblies other than mscorlib.dll what must you do? You must use the /reference compilation switch. The /reference compilation option allows the compiler to make information in the specified libraries available to the source that is currently being compiled. The /r switch is equivalent to /reference. 4. What is the code produced by a.net compiler called? Microsoft intermediate language (MSIL), sometimes called managed code.

35 Module 2: Introduction to a Managed Execution Environment What.NET component compiles MSIL into CPU specific native code? The just-in-time (JIT) compiler. 6. What feature of.net ensures that object memory is freed? The garbage collection process.

36 THIS PAGE INTENTIONALLY LEFT BLANK