Unit-1fi.pdf

DOT Net Technologies Unit 1

Sikkim Manipal University Page No. 1

Unit 1 Introduction to Microsoft .Net Framework

Structure:

1.1 Introduction to .Net Platform

Objectives

1.2 Features of .Net Platform

1.3 Components of .Net Architecture

1.4 Assemblies Overview

1.5 Summary

1.6 Self Assessment Questions

1.7 Terminal Questions

1.8 Answers to Self Assessment Questions

1.1 Introduction to .Net Platform

The Microsofts .Net platform encompasses a virtual machine that abstracts

away much of the windows API from development. It includes a class library

with more functionality than any other created to date, and a development

environment that spans multiple languages. It provides an architecture that

makes multiple language integration simple and straightforward. This is the

first development platform designed from the ground up with Internet in

mind.

.Net is designed and intended for highly distributed software, making

Internet functionality and interoperability easier and more transparent to

include in systems than ever before. Microsoft has taken many of the best

ideas from the industry, combined with some ideas of their own, and brought

them altogether into one coherent package.



Objectives:

The .Net Framework is an amazing technology introduced by Microsoft

which helps to build web applications.

At the end of this unit the student would be able to:

Describe in brief about .Net Platform along with its applications

Explain the various features of .Net platform

Describe the components of .Net Architecture

Discuss regarding the role of assemblies in application execution

1.2 Features of .Net Platform

The .NET Framework is an integral Windows component that supports

building and running the next generation of applications and XML Web

services. The .NET Framework is designed to fulfill the following objectives:

To provide a consistent object-oriented programming environment

whether object code is stored and executed locally, executed locally but

Internet-distributed, or executed remotely.

To provide a code-execution environment that minimizes software

deployment and versioning conflicts.

To provide a code-execution environment that promotes safe execution

of code, including code created by an unknown or semi-trusted third

party.

To provide a code-execution environment that eliminates the

performance problems of scripted or interpreted environments.

To make the developer experience consistency across widely varying

types of applications, such as Windows-based applications and Web-

based applications.

To build all communication on industry standards to ensure that code

based on the .NET Framework can integrate with any other code.



The .NET Framework has two main components: the common language

runtime and the .NET Framework class library. The common language

runtime is the foundation of the .NET Framework. You can think of the

runtime as an agent that manages code at execution time, providing core

services such as memory management, thread management, and remoting,

while also enforcing strict type safety and other forms of code accuracy that

promote security and robustness. In fact, the concept of code management

is a fundamental principle of the runtime. Code that targets the runtime is

known as managed code, while code that does not target the runtime is

known as unmanaged code. The class library, the other main component of

the .NET Framework, is a comprehensive, object-oriented collection of

reusable types that you can use to develop applications ranging from

traditional command-line or graphical user interface (GUI) applications to

applications based on the latest innovations provided by ASP.NET, such as

Web Forms and XML Web services.

The .NET Framework can be hosted by unmanaged components that load

the common language runtime into their processes and initiate the execution

of managed code, thereby creating a software environment that can exploit

both managed and unmanaged features. The .NET Framework not only

provides several runtime hosts, but also supports the development of third-

party runtime hosts.

For example, ASP.NET hosts the runtime to provide a scalable, server-side

environment for managed code. ASP.NET works directly with the runtime to

enable ASP.NET applications and XML Web services, both of which are

discussed later in this topic.

Internet Explorer is an example of an unmanaged application that hosts the

runtime (in the form of a MIME type extension). Using Internet Explorer to

host the runtime enables you to embed managed components or Windows



Forms controls in HTML documents. Hosting the runtime in this way makes

managed mobile code (similar to Microsoft ActiveX controls) possible,

but with significant improvements that only managed code can offer, such

as semi-trusted execution and isolated file storage.

The figure 1.1 shows the relationship of the common language runtime and

the class library to your applications and to the overall system. It also shows

how managed code operates within a larger architecture.

Figure 1.1: Relationship between Common Language Runtime (CLR) and

Class Library

.NET Framework Class Library

The .NET Framework class library is a collection of reusable types that

tightly integrate with the common language runtime. The class library is

object oriented, providing types from which your own managed code can

derive functionality. This not only makes the .NET Framework types easy to

use, but also reduces the time associated with learning new features of the

.NET Framework. In addition, third-party components can integrate

seamlessly with classes in the .NET Framework.



For example, the .NET Framework collection classes implement a set of

interfaces that you can use to develop your own collection classes. Your

collection classes will blend seamlessly with the classes in the .NET

Framework.

As you would expect from an object-oriented class library, the .NET

Framework types enable you to accomplish a range of common

programming tasks, including tasks such as string management, data

collection, database connectivity, and file access. In addition to these

common tasks, the class library includes types that support a variety of

specialized development scenarios. For example, you can use the .NET

Framework to develop the following types of applications and services:

Console applications.

Windows GUI applications (Windows Forms).

Windows Presentation Foundation (WPF) applications.

ASP.NET applications.

Web services.

Windows services.

Service-oriented applications using Windows Communication

Foundation (WCF).

Workflow-enabled applications using Windows Workflow Foundation

(WF).

For example, the Windows Forms classes are a comprehensive set of

reusable types that vastly simplify Windows GUI development. If you write

an ASP.NET Web Form application, you can use the Web Forms classes.



1.3 Components of .Net Architecture

The major components of the .Net framework are shown in the figure 1.2

below:

Figure 1.2: Major Components of .Net Framework

At the lowest level, the framework starts with Memory Management and

Component Loading and goes all the way up to multiple ways of rendering

user and program interfaces.

The middle layer provides any system level capability that a developer

needs.

The base to the Framework is the Common Language Runtime (CLR). The

CLR is the heart of the .Net framework, the engine that drives the key

functionality.

For example the CLR includes a common system of data types. These

common types plus a standard interface convention, make cross language

Web Services Web Forms

ASP.NET Application Services

ASP.NET Windows Forms

Controls Drawing

Windows Application Services

.NET Framework Base Classes

ADO.NET XML

Net

Threading IO

Security Diagnostics Etc.

Memory Management Common Type System Life Cycle Monitoring

Common Language Runtime



inheritance possible. The CLR also does the reference counting for objects

and handles garbage collection. The middle layer consists of standard

system services such as ADO.NET AND XML. These services are

controlled by the framework making them universally available and

standardizing their usage across languages. The top layer has the user and

program interfaces.

Windows Forms: They provide a new way to create standard Win32

desktop applications, based on the Windows Foundation Classes (WFC)

produced for J++.

Web Forms: They provide a powerful forms based UI for the web.

Web Services: They provide a mechanism for programs to communicate

over the Internet using SOAP. They provide an analog of COM and DCOM

for object brokering and interfacing, but based on Internet technologies so

that allowance is made for integration even with non Microsoft platforms.

The Web Forms and Web Services comprise the Internet interface portion of

the .Net, and are implemented through a section of the .Net Framework

referred to as ASP.NET. All the above objects are available to any language

based on the .Net platform. For completeness, there is also a console

interface that allows creation of character based applications.



The Common Language Runtime

Figure 1.3: Major Components of Common Language Runtime (CLR)

A runtime is an environment in which the programs are executed. The CLR

is an environment used for running the .Net applications that have been

compiled to a common language, namely Microsoft Intermediate Language

(MSIL) often referred to as IL.

The Execution Support: It contains most of the capabilities normally

associated with the language runtime (viz. VBRUNxxx.dll runtime of Visual

Basic).

Garbage Collection: The .NET Framework's garbage collector manages

the allocation and release of memory for your application. Each time you

use the new operator to create an object, the runtime allocates memory for

the object from the managed heap. As long as address space is available in

the managed heap, the runtime continues to allocate space for new objects.

However, memory is not infinite. Eventually the garbage collector must

perform a collection in order to free some memory. The garbage collector's

optimizing engine determines the best time to perform a collection, based

upon the allocations being made. When the garbage collector performs a

Common Type System

(Data, Types, etc.)

Intermediate Language (IL) To native code compilers

Execution Support (traditional runtime

functions)

Security

Garbage Collection, Stack Walk, Code Manager

Class Loader and Memory Layout



collection, it checks for objects in the managed heap that are no longer

being used by the application and performs the necessary operations to

reclaim their memory.

Stack Walk: This concept is helpful to anyone interested in building a

profiler to examine managed applications. The following lines describe how

you can program your profiler to walk managed stacks in the common

language runtime (CLR) of the .NET Framework.

The profiling API in version 2.0 of the CLR has a new method named

DoStackSnapshot that lets your profiler walk the call stack of the

application you're profiling. Version 1.1 of the CLR exposed similar

functionality through the in-process debugging interface. But walking the call

stack is easier, more accurate, and more stable with DoStackSnapshot.

The DoStackSnapshot method uses the same stack walker used by the

garbage collector, security system, exception system, and so on.

Access to a full stack trace gives users of your profiler the ability to get the

big picture of what's going on in an application when something interesting

happens. Depending on the application and on what a user wants to profile,

you can imagine a user wanting a call stack when an object is allocated,

when a class is loaded, when an exception is thrown, and so on. Even

getting a call stack for something other than an application event, for

example, a timer event would be interesting for a sampling profiler.

Looking at hot spots in code becomes more enlightening when you can see

who called the function containing the hot spot.

We are going to focus on getting stack traces with the DoStackSnapshot

API. Another way to get stack traces is by building shadow stacks: you can

hook FunctionEnter and FunctionLeave to keep a copy of the managed

call stack for the current thread. Shadow stack building is useful if you need

stack information at all times during application execution, and if you don't



mind the performance cost of having your profiler's code run on every

managed call and return. The DoStackSnapshot method is best if you

need slightly sparser reporting of stacks, such as in response to events.

Even a sampling profiler taking stack snapshots every few milliseconds is

much sparser than building shadow stacks. So DoStackSnapshot is well

suited for sampling profilers.

Class Loader: Normally, the Java Virtual Machine loads classes from the

local file system in a platform-dependent manner. For example, on UNIX

systems, the Virtual Machine loads classes from the directory defined by the

CLASSPATH environment variable.

However, some classes may not originate from a file; they may originate

from other sources, such as the network, or they could be constructed by an

application. The method defineClass converts an array of bytes into an

instance of class Class. Instances of this newly defined class can be created

using the newInstance method in class Class.

The methods and constructors of objects created by a class loader may

refer other classes. To determine the class(es) referred to, the Java Virtual

Machine calls the loadClass method of the class loader that originally

created the class. If the Java Virtual Machine only needs to determine if the

class exists and if it does exist to know its superclass, the resolve flag is set

to false. However, if an instance of the class is being created or any of its

methods are being called, the class must also be resolved. In this case the

resolve flag is set to true, and the resolveClass method should be called.

For example, an application could create a network class loader to

download class files from a server. Sample code might look like:

ClassLoader loader = new NetworkClassLoader(host, port);

Object main = loader.loadClass("Main", true).newInstance();

. . .



Hosts such as Microsoft Internet Explorer, ASP.NET, and the Windows shell

load the common language runtime into a process, create an application

domain in that process, and then load and execute user code in that

application domain when running a .NET Framework application. In most

cases, you do not have to worry about creating application domains and

loading assemblies into them because the runtime host performs those

tasks.

However, if you are creating an application that will host the common

language runtime, creating tools or code you want to unload

programmatically, or creating pluggable components that can be unloaded

and reloaded on the fly, you will be creating your own application domains.

Even if you are not creating a runtime host, this section provides important

information on how to work with application domains and assemblies loaded

in these application domains.

The common language runtime allows you to add keyword-like descriptive

declarations, called attributes, to annotate programming elements such as

types, fields, methods, and properties. Attributes are saved with the

metadata of a Microsoft .NET Framework file and can be used to describe

your code to the runtime or to affect application behavior at run time. While

the .NET Framework supplies many useful attributes, you can also design

and deploy your own.

Security: The .Net framework includes an integrated security model that

grants permission to resources based on evidence found in the assemblies.

The common language runtime and the .NET Framework provide many

useful classes and services that enable developers to easily write security

code. These classes and services also enable system administrators to

customize the access that code has to protected resources. In addition, the



runtime and the .NET Framework provide useful classes and services that

facilitate the use of cryptography and role-based security.

1.4 Assemblies Overview

Assemblies are a fundamental part of programming with the .NET

Framework. An assembly performs the following functions:

It contains code that the common language runtime executes. Microsoft

intermediate language (MSIL) code in a portable executable (PE) file will

not be executed if it does not have an associated assembly manifest.

Note that each assembly can have only one entry point (that is, DllMain,

WinMain, or Main).

It forms a security boundary. An assembly is the unit at which

permissions are requested and granted.

It forms a type boundary. Every type's identity includes the name of the

assembly in which it resides. A type called MyType loaded in the scope

of one assembly is not the same as a type called MyType loaded in the

scope of another assembly.

It forms a reference scope boundary. The assembly's manifest contains

assembly metadata that is used for resolving types and satisfying

resource requests. It specifies the types and resources that are exposed

outside the assembly. The manifest also enumerates other assemblies

on which it depends.

It forms a version boundary. The assembly is the smallest versionable

unit in the common language runtime; all types and resources in the

same assembly are versioned as a unit. The assembly's manifest

describes the version dependencies you specify for any dependent

assemblies. For more information about versioning, see Assembly

Versioning.



It forms a deployment unit. When an application starts, only the

assemblies that the application initially calls must be present. Other

assemblies, such as localization resources or assemblies containing

utility classes, can be retrieved on demand. This allows applications to

be kept simple and thin when first downloaded. For more information

about deploying assemblies, see Deploying Applications.

It is the unit at which side-by-side execution is supported. For more

information about running multiple versions of an assembly, see

Assemblies and Side-by-Side Execution.

Assemblies can be static or dynamic. Static assemblies can include .NET

Framework types (interfaces and classes), as well as resources for the

assembly (bitmaps, JPEG files, resource files, and so on). Static assemblies

are stored on disk in portable executable (PE) files. You can also use the

.NET Framework to create dynamic assemblies, which are run directly from

memory and are not saved to disk before execution. You can save dynamic

assemblies to disk after they have executed.

There are several ways to create assemblies. You can use development

tools, such as Visual Studio 2005, that you have used in the past to create

.dll or .exe files. You can use tools provided in the Windows Software

Development Kit (SDK) to create assemblies with modules created in other

development environments. You can also use common language runtime

APIs, such as Reflection.Emit, to create dynamic assemblies.

Benefits of Assemblies

Assemblies are designed to simplify application deployment and to solve

versioning problems that can occur with component-based applications.

End users and developers are familiar with versioning and deployment

issues that arise from today's component-based systems. Some end users

have experienced the frustration of installing a new application on their



computer, only to find that an existing application has suddenly stopped

working. Many developers have spent countless hours trying to keep all

necessary registry entries consistent in order to activate a COM class.

Many deployment problems have been solved by the use of assemblies in

the .NET Framework. Because they are self-describing components that

have no dependencies on registry entries, assemblies enable zero-impact

application installation. They also simplify uninstalling and replicating

applications.

Versioning Problems

Currently two versioning problems occur with Win32 applications:

1. Versioning rules cannot be expressed between pieces of an application

and enforced by the operating system. The current approach relies on

backward compatibility, which is often difficult to guarantee. Interface

definitions must be static, once published, and a single piece of code

must maintain backward compatibility with previous versions.

Furthermore, code is typically designed so that only a single version of it

can be present and executing on a computer at any given time.

2. There is no way to maintain consistency between sets of components

that are built together and the set that is present at run time.

These two versioning problems combine to create DLL conflicts, where

installing one application can inadvertently break an existing application

because a certain software component or DLL was installed that was not

fully backward compatible with a previous version. Once this situation

occurs, there is no support in the system for diagnosing and fixing the

problem.

An End to DLL Conflicts

Microsoft Windows 2000 began to fully address these problems. It

provides two features that partially fix DLL conflicts:



Windows 2000 enables you to create client applications where the

dependent .dll files are located in the same directory as the application's

.exe file. Windows 2000 can be configured to check for a component in

the directory where the .exe file is located before checking the fully

qualified path or searching the normal path. This enables components to

be independent of components installed and used by other applications.

Windows 2000 locks files that are shipped with the operating system in

the System32 directory so they cannot be inadvertently replaced when

applications are installed.

The common language runtime uses assemblies to continue this evolution

toward a complete solution to DLL conflicts.

The Assembly Solution

To solve versioning problems, as well as the remaining problems that lead

to DLL conflicts, the runtime uses assemblies to do the following:

Enable developers to specify version rules between different software

components.

Provide the infrastructure to enforce versioning rules.

Provide the infrastructure to allow multiple versions of a component to

be run simultaneously (called side-by-side execution).

Assembly Contents

In general, a static assembly can consist of four elements:

The assembly manifest, which contains assembly metadata.

Type metadata.

Microsoft Intermediate Language (MSIL) code that implements the

types.

A set of resources.

Only the assembly manifest is required, but either types or resources are

needed to give the assembly any meaningful functionality. There are several



ways to group these elements in an assembly. You can group all elements

in a single physical file, which is shown in the following illustration:

Single-file Assembly

MyAssembly.dll

Assembly Manifest

Type metadata

MSIL Code

Resources

Alternatively, the elements of an assembly can be contained in several files.

These files can be modules of compiled code (.netmodule), resources (such

as .bmp or .jpg files), or other files required by the application. Create a

multi-file assembly when you want to combine modules written in different

languages and to optimize downloading an application by putting seldom

used types in a module that is downloaded only when needed.

In the following illustration, the developer of a hypothetical application has

chosen to separate some utility code into a different module and to keep a

large resource file (in this case a .bmp image) in its original file. The .NET

Framework downloads a file only when it is referenced; keeping infrequently

referenced code in a separate file from the application optimizes code

download.

Multi-file Assembly Util.netmodule

Assembly Manifest Type metadata

Type metadata MSIL Code

MSIL Code Graphic.bmp

Resources



Note: The files that make up a multifile assembly are not physically linked

by the file system. Rather, they are linked through the assembly manifest

and the common language runtime manages them as a unit.

In this illustration, all three files belong to an assembly, as described in the

assembly manifest contained in MyAssembly.dll. To the file system, they are

three separate files. Note that the file Util.netmodule was compiled as a

module because it contains no assembly information. When the assembly

was created, the assembly manifest was added to MyAssembly.dll,

indicating its relationship with Util.netmodule and Graphic.bmp.

As you currently design your source code, you make explicit decisions about

how to partition the functionality of your application into one or more files.

When designing .NET Framework code, you will make similar decisions

about how to partition the functionality into one or more assemblies.

Assembly Manifest

Every assembly, whether static or dynamic, contains a collection of data that

describes how the elements in the assembly relate to each other. The

assembly manifest contains this assembly metadata. An assembly manifest

contains all the metadata needed to specify the assembly's version

requirements and security identity, and all metadata needed to define the

scope of the assembly and resolve references to resources and classes.

The assembly manifest can be stored in either a PE file (an .exe or .dll) with

Microsoft intermediate language (MSIL) code or in a standalone PE file that

contains only assembly manifest information.



The following illustration shows the different ways the manifest can be

stored:

Types of Assemblies

For an assembly with one associated file, the manifest is incorporated into

the PE file to form a single-file assembly. You can create a multifile

assembly with a standalone manifest file or with the manifest incorporated

into one of the PE files in the assembly.

Each assembly's manifest performs the following functions:

Enumerates the files that make up the assembly.

Governs how references to the assembly's types and resources map to

the files that contain their declarations and implementations.

Enumerates other assemblies on which the assembly depends.

Provides a level of indirection between consumers of the assembly and

the assembly's implementation details.

Renders the assembly self-describing.

A Single file Assembly A Multi file Assembly

File1.dll

Manifest

file2.dll Graphic.jpg Logo.bmp

Manifest



Assembly Manifest Contents

The following table shows the information contained in the assembly

manifest. The first four itemsthe assembly name, version number, culture,

and strong name informationmake up the assembly's identity.

Information Description

Assembly name A text string specifying the assembly's name.

Version number A major and minor version number, and a revision and build number. The common language runtime uses these numbers to enforce version policy.

Culture Information on the culture or language the assembly supports. This information should be used only to designate an assembly as a satellite assembly containing culture- or language-specific information. (An assembly with culture information is automatically assumed to be a satellite assembly.)

Strong name information

The public key from the publisher if the assembly has been given a strong name.

List of all files in the assembly

A hash of each file contained in the assembly and a file name. Note that all files that make up the assembly must be in the same directory as the file containing the assembly manifest.

Type reference information

Information used by the runtime to map a type reference to the file that contains its declaration and implementation. This is used for types that are exported from the assembly.

Information on referenced assemblies

A list of other assemblies that are statically referenced by the assembly. Each reference includes the dependent assembly's name, assembly metadata (version, culture, operating system, and so on), and public key, if the assembly is strong named.

You can add or change some information in the assembly manifest by using

assembly attributes in your code. You can change version information and

informational attributes, including Trademark, Copyright, Product, Company,

and Informational Version.



1.5 Summary

This chapter provides an introduction and overview of the Microsofts latest

.Net Platform, which has interoperability and cross platform development

features. It starts with the basic features of .Net platform and describes the

major components of .Net platform. It then provides with a clear picture of

the .Net Architecture and its components. It then ends with providing the

basic view of Assemblies and their usage in application development.

Self Assessment Questions

1. The .NET Framework can be hosted by ___________ components that

load the common language runtime into their processes and initiate the

execution of managed code.

2. ASP.NET hosts the ______ to provide a scalable, server-side

environment for managed code.

3. The ____________ is a collection of reusable types that tightly integrate

with the common language runtime.

4. The _______ Provide a mechanism for programs to communicate over

the Internet using SOAP.

5. The concept of _________ is helpful to anyone interested in building a

profiler to examine managed applications.

6. The ______ assemblies are stored on disk in portable executable (PE)

files.

1.7 Terminal Questions

1. Discuss the features of .Net platform. (Refer to 1.2)

2. Discuss the architecture of .Net with a supporting diagram (Refer to 1.3)

3. Describe the Assemblies in .Net environment. (Refer to 1.4)



1.8 Answers to Self Assessment Questions

1. unmanaged

2. runtime

3. NET Framework class library

4. Web Services

5. Stack Walk

6. Static

Unit-1fi.pdf

Documents

Transcript of Unit-1fi.pdf