Anant Jain

Course - MCA Semester - 5th Assingnment ON - . (DOT) Net Technologies Code - MC0081

Question 1Describe the steps involved in creating classes and objects with the help of a program in C#.

Answer

A class is a construct that enables you to create your own custom types by grouping together variables of other types, methods and events. A class is like a blueprint. It defines the data and behavior of a type. If the class is not declared as static, client code can use it by creating objects or instances which are assigned to a variable. The variable remains in memory until all references to it go out of scope. At that time, the CLR marks it as eligible for garbage collection. If the class is declared as static, then only one copy exists in memory and client code can only access it through the class itself, not an instance variable. For more information, see Static Classes and Static Class Members (C# Programming Guide). Unlike structs, classes support inheritance, a fundamental characteristic of object-oriented programming. Declaring classes public class Customer { //Fields, properties, methods and events go here... } Creating object Customer object1 = new Customer(); Class Inheritance

public class Manager : Employee { // Employee fields, properties, methods and events are inherited // New Manager fields, properties, methods and events go here... }

EXAMPLEpublic class Person { // Field public string name; // Constructor public Person() { name = "unknown"; } // Method public void SetName(string newName) { name = newName;

} } class TestPerson { static void Main() { Person person = new Person(); Console.WriteLine(person.name); person.SetName("John Smith"); Console.WriteLine(person.name); // Keep the console window open in debug mode. Console.WriteLine("Press any key to exit."); Console.ReadKey(); } } /* Output: unknown John Smith */

The End !

Question 2
Describe the following with respect to creating Web Forms in .Net environment: A. Web Form Life Cycle B. Creating a Web Form Write programs with corresponding output screens to demonstrate the above concepts.

Answer
A. Web Form Life Cycle Every request for a page made from a web server causes a chain of events at the server. These events, from beginning to end, constitute the life cycle of the page and all its components. The life cycle begins with a request for the page, which causes the server to load it. When the request is complete, the page is unloaded. From one end of the life cycle to the other, the goal is to render appropriate HTML output back to the requesting browser. The life cycle of a page is marked by the following events, each of which you can handle yourself or leave to default handling by the ASP.NET server:

Initialize: Initialize is the first phase in the life cycle for any page
or control. It is here that any settings needed for the duration of the incoming request are initialized.

Load ViewState: The ViewState property of the control is

populated. The ViewState information comes from a hidden variable on the control, used to persist the state across round trips to the server. The input string from this hidden variable is parsed by the page framework, and the ViewState property is set. This can be modified via the LoadViewState( ) method: This allows ASP.NET to manage the state of your control across page loads so that each control is not reset to its default state each time the page is posted.

Process Postback Data: During this phase, the data sent to

the server in the posting is processed. If any of this data results in a requirement to update the ViewState, that update is performed via the LoadPostData ( ) method.

Load: CreateChildControls ( ) is called, if necessary, to create

and initialize server controls in the control tree. State is restored, and the form controls show client-side data. You can modify the load phase by handling the Load event with the OnLoad method. Send Postback Change Modifications: If there are any state changes between the current state and the previous state, change events are raised via the RaisePostDataChangedEvent ( ) method. Handle Postback Events: The client-side event that caused the postback is handled.

PreRender: This is the phase just before the output is rendered

to the browser. It is essentially your last chance to modify the output prior to rendering using the OnPreRender ( ) method.

Save State: Near the beginning of the life cycle, the persisted
view state was loaded from the hidden variable. Now it is saved back to the hidden variable, persisting as a string object that will complete the round trip to the client. You can override this using the SaveViewState () method.

Render: This is where the output to be sent back to the client

browser is generated. You can override it using the Render method. CreateChildControls ( ) is called, if necessary, to create and initialize server controls in the control tree.

Dispose: This is the last phase of the life cycle. It gives you an
opportunity to do any final cleanup and release references to any expensive resources, such as database connections. You can modify it using the Dispose ( ) method.

B. Creating a Web Form

When you create a new Web site using the Studio adds an ASP.NET page (Web Forms page) named Default.aspx. You can use the Default.aspx page as the home page for your Web site. However, for this walkthrough, you will create and work with a new page. To Add a page to the WEBSITE.

1. Close the Default.aspx page. To do this , right-click the TAB

that display the file name & then click Close.

2. In Solution Explorer, right-click the Web site (for example,

C:\BasicWebSite), & then click Add New Item. The Add New Item dialog box is displayed. The following illustration shows an example of the Add New Item dialog box.

3. In the template list, select Web Form . 4. In the Name box, type First Web Page .
When you created the Web site project, you specified a default language based on the project template that you selected. However, each time a new page or component for your Web site, you can select the programming language for that page or component. You can use different programming languages in the same Web site.

5. Clear the Place code in separate file check box. In this

walkthrough, you are creating a single-file page with the code and HTML in the same page. The code for ASP.NET pages can be located either in the page or in a separate class file.

6. Click Add Visual Studio creates the New page & open It.

Adding HTML to the Page

In this part of the walkthrough, you will add some static text to the page. To add text to the page

1. At the bottom of the document window, click the Design tab to

switch to Design view. Design view displays the page that you are working on in a WYSIWYG-like way. At this point, you do not have any text or controls on the page, so the page is blank except for a dashed line that outlines a rectangle. This rectangle represents a div element on the page.

2. Click inside the rectangle that is outlined by a dashed line. 3. Type Welcome to Visual Web Developer and press ENTER
twice. The following illustration shows the text you typed in Design view.

4. Switch to Source view. You can see the HTML that you created
by typing in Design view, as shown in the following illustration.

The End !

Question 3- Design a simple Window based

form application to perform basic arithmetic operations.

Answer To create a Windows Form: Start Visual Studio Create a Windows application called HelloWorld. From the Toolbox, drag a button control onto the form Click the button on select it. In the Properties window, set the Textproperty to SayHello. To write the code for your application Double-click the button to add an event handler for the Click event. The code Editor will open with the insertion point placed within the event handler. Insert the following code: VB C# C++ F# Jscript Copy MessageBox.Show(Hello, World!); VBC#C++F#Jscript Copy

This language is not supported or no code example is available. J# Copy MessageBox.Show("Hello, World!"); VBC# C++ F# JScript Copy This language is not supported or no code example is available. To test your application Press F5 to run the application When your application is running, click the button and verify that Hello, World! is shown. Close the Windows Form to return to Visual Studio.

The End !

Question 4- Describe the following with respect to

State Management in ASP.Net: A. Cookies in ASP.NET B. Session State C. Application State

Answer A - Cookies in ASP.NET : Web applications can store small

pieces of data in the clients Web browser by using cookies. A cookie is a small amount of data that is stored either in a text file on the client file system (if the cookie is persistent) or in memory in the client browser session (if the cookie is temporary). The most common use of cookies is to identify a single user as he or she visits multiple Web pages.

Reading and Writing Cookies:

A Web application creates a cookie by sending it to the client as a header in an HTTP response. The Web browser then submits the same cookie to the server with every new request. Create a cookie -> add a value to the Response.Cookies HttpCookieCollection. Read a cookie -> read values in Request.Cookies.

Example:
// Check if cookie exists, and display it if it does if (Request.Cookies["lastVisit"] != null) // Encode the cookie in case the cookie contains client-side script Label1.Text= Server.HtmlEncode(Request.Cookies["lastVisit"].Value); else Label1.Text = "No value defined"; // Define the cookie for the next visit

Response.Cookies["lastVisit"].Value= DateTime.Now.ToString();Response.Cookies["lastVisit"].E xpires = DateTime.Now.AddDays(1); If you do not define the Expires property, the browser stores it in memory and the cookie is lost if the user closes his or her browser. To delete a cookie, overwrite the cookie and set an expiration date in the past. You cant directly delete cookies because they are stored on the clients computer. Controlling the Cookie Scope: By default, browsers wont send a cookie to a Web site with a different hostname. You can control a cookies scope to either limit the scope to a specific folder on the Web server or expand the scope to any server in a domain. To limit the scope of a cookie to a folder, set the Path property, as the following example demonstrates:

Example:
Response.Cookies["lastVisit"].Path = "/Application1"; Through this the scope is limited to the /Application1 folder that is the browser submits the cookie to any page with in this folder and not to pages in other folders even if the folder is in the same server. We can expand the scope to a particular domain using the following statement:

Example:
Response.Cookies[lastVisit].Domain = Contoso;

Storing Multiple Values in a Cookie:

Though it depends on the browser, you typically cant store more than 20 cookies per site, and each cookie can be a maximum of 4 KB in length. To work around the 20-cookie limit, you can store multiple values in a cookie, as the following code demonstrates:

Example:
Response.Cookies["info"]["visit"].Value= DateTime.Now.ToString(); Response.Cookies["info"]["firstName"].Value = "Tony"; Response.Cookies["info"]["border"].Value = "blue"; Response.Cookies["info"].Expires= DateTime.Now.AddDays(1); Running the code in this example sends a cookie with the following value to the Web browser: (visit=4/5/2006 (border=blue) 2:35:18 PM) (firstName=Tony)

Query Strings: Query strings are commonly used to

store variables that identify specific pages, such as search terms or page numbers. A query string is information that is appended to the end of a page URL. A typical query string might look like the following realworld example: http://support.microsoft.com/Default.aspx?kbid=3 15233 In this example, the URL identifies the Default.aspx page. The query string (which starts with a question mark [?]) contains a single parameter named kbid, and a value for that parameter, 315233. Query strings can also have multiple parameters, such as the following real-world URL, which specifies a language and query when searching the Microsoft.com Web site: http://search.microsoft.com/results.aspx?mkt =en-US&setlang=enUS&q=hello+world

Limitations for Query Strings:

A. Some Browsers and client devices impose a 2083 character limit on the length of the URL. B.You must submit the page using an HTTP GET command in order for query string values to be available during page processing. Therefore, you shouldnt add query strings to button targets in forms.

C. You must manually add query string values to every hyperlink that the user might click.

Example:
Label1.Text="User:"+ Server.HtmlEncode(Request.QueryString["user"]) + ", Prefs: " + Server.HtmlEncode(Request.QueryString["prefs"]) + ", Page: " + Server.HtmlEncode(Request.QueryString["page"]);

B- Session State:
ASP.NET allows you to save values using session state, a storage mechanism that is accessible from all pages requested by a single Web browser session. Therefore, you can use session state to store userspecific information. Session state is similar to application state, except that it is scoped to the current browser session. If different users are using your application, each user session has a different session state. In addition, if a user leaves your application and then returns later after the session timeout period, session state information is lost and a new session is created for the user. Session state is stored in the Session key/value dictionary.

You can use session state to accomplish the following tasks: Uniquely identify browser or client-device requests and map them to individual session instances on the server. This allows you to track which pages a user saw on your site during a specific visit. Store session-specific data on the server for use across multiple browser or client-device requests during the same session. This is perfect for storing shopping cart information. Raise appropriate session management events. In addition, you can write application code leveraging these events. ASP.NET session state supports several different storage options for session data:

A. InProc Stores session state in memory on the

Web server. This is the default, and it offers much better performance than using the ASP.NET state service or storing state information in a database server. InProc is fine for simple applications, but robust applications that use multiple Web servers or must persist session data between application restarts should use State Server or SQLServer.

B. StateServer Stores session state in a service

called the ASP.NET State Service. This ensures

that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm. ASP.NET State Service is included with any computer set up to run ASP.NET Web applications; however, the service is set up to start manually by default. Therefore, when configuring the ASP.NET State Service, you must set the startup type to Automatic.

C. SQLServer Stores session state in a SQL Server

database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm. On the same hardware, the ASP.NET State Service outperforms SQLServer. However, a SQL Server database offers more robust data integrity and reporting capabilities.

D. Custom Enables you to specify a custom storage

provider. You also need to implement the custom storage provider.

E. Off Disables session state. You should disable

session state if you are not using it to improve performance.

Advantages;
Advantages of Client Side State Management: 1- Better Scalability: With server-side state management, each client that connects to the Web server consumes memory on the Web server. If a Web site has hundreds or thousands of simultaneous users, the memory consumed by storing state management information can become a limiting factor. Pushing this burden to the clients removes that potential bottleneck. 2- Supports multiple Web servers: With client-side state management, you can distribute incoming requests across multiple Web servers with no changes to your application because the client provides all the information the Web server needs to process the request. With server-side state management, if a client switches servers in the middle of the session, the new server does not necessarily have access to the clients state information. You can use multiple servers with server-side state management, but you need either intelligent load-balancing (to always forward requests from a client to the same server) or centralized state management (where state is stored in a central database that all Web servers access).

Advantages of Server Side State Management:

1Better security: Client-side state management information can be captured (either in transit or while it is stored on the client) or maliciously modified. Therefore, you should never use clientside state management to store confidential information, such as a password, authorization level, or authentication status. Reduced bandwidth: If you store large amounts of state management information, sending that information back and forth to the client can increase bandwidth utilization and page load times, potentially increasing your costs and reducing scalability. The increased bandwidth usage affects mobile clients most of all, because they often have very slow connections. Instead, you should store large amounts of state management data (say, more than 1 KB) on the server...

2-

C- Application State: ASP.NET allows you to save

values using application state, a global storage mechanism that is accessible from all pages in the Web application. Application state is stored in the Application key/value dictionary. Once you add your applicationspecific information to application state, the server manages it, and it is never exposed to the client. Application state is a great place to store information that is not user-specific. By storing it in the application state, all pages can access data from a single location in memory, rather than keeping separate copies of the data. Data stored in the Application object is not permanent and is lost any time the application is restarted. ASP.NET provides three events that enable you to initialize Application variables (free resources when the application shuts down) and respond to Application errors: Application_Start: Raised when the application starts. This is the perfect place to initialize Application variables. Application_End: Raised when an application shuts down. Use this to free application resources and perform logging. Application_Error: Raised when an unhandled error occurs. Use this to perform error logging........

The End !

Question 5- Describe the following with respect to

Web Services in .Net: A. Writing and Testing a Web Service B. Implementing a Web Service Client .

Answer A. Writing and Testing a Web Service

How do you test an ASMX Web service? Simple: just call it in your browser. To demonstrate, copy Calc.asmx to wwwroot and type http://localhost/calc.asmx in your browsers address bar. Youll be greeted with the screen shown in Figure 8.6. What happened? ASP.NET responded to the HTTP request for Calc.asmx by generating an HTML page that describes the Web service. The name and description in the ASMX files WebService attribute appear at the top of the page. Underneath is a list of Web methods that the service exposes, complete with the descriptions spelled out in the WebMethod attributes.

Calc.asmx as seen in Internet Explorer Click Add near the top of the page, and ASP.NET displays a page that you can use to test the Add method (Figure 8.7). ASP.NET knows the method name and signature because it reads them from the metadata in the DLL it compiled from Calc.asmx. It even generates an HTML form that you can use to call the Add method with your choice of inputs. Type 2 and 2 into the a and b boxes and click Invoke. The XML returned by the Web method appears in a separate browser window.

XML returned by the Add method The forms that ASP.NET generates on the fly from ASMX files enable you to test the Web services that you write without writing special clients to test them with. They also let you explore a Web service built with the .NET Framework simply by pointing your browser to it. For kicks, type the following URL into your browsers address bar: http://terraservice.net/terraservice.asmx Thats the URL of the Microsoft TerraService, an ultra-cool Web service that provides a programmatic interface to a massive database of geographic data known as the Microsoft TerraServer. Dont worry about the details just yet; youll be using TerraService to build a Web service client later in this chapter. But do notice how much you can learn about TerraService simply by viewing the page that ASP.NET generated for it.

B- Implementing a Web Service Client Now that youve seen Web services up close and personal, its time to learn about Web service clients that is, applications that use, or consume, Web methods. Its easy to write Web services. Writing Web service clients is even easier, thanks to some high-level support lent by the .NET Framework class library (FCL) and a code-generator named Wsdl.exe. If you have a WSDL contract describing a Web service. Once a client has a WSDL contract describing a Web service it has all the information it needs to make calls to that Web services. But when you publish a web service by making it available on a Web server , how do clients find out where to get a WSDL contract? For that matter, how do clients know that your Web service exists in the first place? The answer comes in two parts: DISCO and universal Description, Discovery, and Integration ,better know as UDDI . The Former is a file-based information mechanism for local Web Service discovery that is, for getting a list of available Web services from DISCO file developed on Web severs. The latter is a global web service directory that is itself implemented as a Web service. UDDI is discussed in the next section.

The DSICO (short for discovery) protocol is a simple one that revolves around XML-based DISCO file .The idea is that you publish a DISCO file on your Web server that describes the Web server that describes the Web services available on it and perhaps on other servers as well .Clients can interrogate the DISCO file to find out what web services are available and where the services WSDL contracts can be found .As an example ,

suppose you publish two web services and their URLs are follows: http://www.wintellect.com/calc.asmx http://www.wintellect.com/locator.asmx To advertise these Web services , you can deploy the following DISCO file at a well known URL on your server. The contractRef element identifies the URLs of the Web servicesWSDL contract. URLs can be absolute or relative . The optional docRef attributes identify the locations of document describing the Web services, which, because of the selfdocumenting nature of web services built with the .NET Framework are typically the ASMX file themselves:

<?xml version =1.0?> <discovery xmlns=http://schemas.xmlsoap.org/disco/ xmlns:scl=http://schemas.xmlsoap.org/disco/scl/> <scl:contractRef ref=http://www.wintellect.com/calc.asmx?wsdl docRef=http://www.wintellect.com/calc.asmx/> <scl:contractRef ref=http://www.wintellect.com/locator.asmx?wsdl docRef=http://www.wintellect.com/locator.asmx/> </discover>

If youd prefer ,you can write DISCO files for individual Web services and reference Them in master DISCO file using discoveryRef element . Heres a DISCO file that points to other DISCO file that points to other DISCO files .Once more URLs can be absolute or relative:

<?xml version=1.0?> <discovery xmlns=http://schemas.xmlsoap.org/disco/> <discoveryRef ref =http://www.wintellect.com/calc.disco/> <discoveryRef ref =http://www.wintellect.com/locator.disco/> </discover>

A third option is to deploy a VSDISCO to enable dynamic discovery . The following VSDISCO file automatically exposes all ASMX and DISCO files in a host directory and its subdirectories ,with the exception of these subdirectories noted with exclude element:

<?xml version=1.0?> <dynamic discovery xmlns=urn:schemas-dynamicdiscovery:disco .2000-30-17> <exclude path=_vti_cnf/> <exclude path=_vti_pvt/> <exclude path=_vti_log/> <exclude path=_vti_script/> <exclude path=_vti_txt/> <dynamic discovery>

How does dynamic discovery work ? ASP. NET maps the file name extension.vsdisco to an HTTP handler that scans the host directory and subdirectory for ASMX and DISCO files and returns a dynamically generate DISCO document .A client that request a VSDISCO file gets back what appears to be static DISCO document For security reasons ,Microsoft disable dynamic discovery just before version 1.0 of the .NET Framework shipped .You can re-enable it by un-commenting the line in the httpHandlers section of Machine .config that maps *.vsdisco to System.WebServices.DiscoveryRequestHandler and granting the ASPNET account permission to access the IIS metabase Microsoft highly discourages dynamic discovery for fear of compromising your Web server ,and a bug in version1.0 of the .NET Framework SDK prevent most DISCO-aware tools from

working with VSDISCO anyway . My advice is to forget that VSDISCO files even exist and use static DISCO Files instead. To further simplify Web services discovery , you can link to a master DISCO file from your sites default HTML document . For example ,suppose the default HTML document at www.wintellect.com is default .html and that the same directory also holds a directory document named Default.disco. Including the following HTML in Default.html enables most tools that read DISCO files to accept the URL www.wintellect.com

<html> <head> <link type=text/htmlrel=alternatehref=Default.disco> </head> </html> Visual Studio.NET reads DISCO files; so does the disco.exe utility that comes with the .NET Framework SDK Discos chief disadvantages is thts at you cant read Disco file if you dont have its URL . So how do you find a web service if you dont even have a URL to start with ?can you spell U-D-D-I?

The End !

Question 6 - Describe the following with respect to

Web site deployment in ASP.Net: A. Creating Application Pools (IIS 6.0). B. Deploying ASP.NET Applications.

Answer
A.-Creating Application Pools (IIS 6.0).When you run IIS 6.0 in worker process isolation mode, you can isolate different Web application or Web sites in pools, which are called Application Pools. An application pool is a group of URLs that are routed to one or more worker processes that share the same configuration. The URLs that you assign to an application pool can be for an application, a Web site, a Web directory, or virtual directory. In an application pool, process boundaries separate each worker process from other worker processes so that when an application is routed to one application pool, application in other application in other application pools do not affect that application. By using an application pool, you can assign specific configuration settings to a worker process that services a group of applications. For example, you can configure worker process recycling, which offers several configuration options to match the need of each application. If, for example, you suspect that an application has a memory leak ,you might configure the application pools worker process to recycle when its memory use reaches a certain threshold . If another application fails because of the volume of request that it receives, you can set the application pools worker process to recycle when the application exceeds specified number of requests.

By creating new application pools and assigning Web sites and applications to them ,you can make your server more efficient, reliable , and secure, and ensure that your application remain available even when a worker process serving an application pool is recycled because of faulty application.

Configuring Application Pools in IIS6.0(IIS 6.0)

An application pool is configuration that links one or more application to a set of one or more worker processes. Because applications in an application pool are separated from other applications by worker process boundaries, an application in one application pool is not affected by problem caused by application in other application pools. By creating new application pools and assigning Web site and applications to them, you can make your server more efficient and reliable, as well as making your other application always available, even when the worker process serving the new application pool has problems.

Guidelines for Creating Application Pools

To isolate Web application on a Web site from Web application on other sites worker running on the same computer, create an individual application pool for each Web site. For enhanced security, configure a unique user account (process identify) for each application pool. Use an account with the least user right possible, such as Network services in the IIS_WPG group. If there is a test version of an application on the same server with the production version of the application pools this isolates the test version of the application. As a design consideration , if you

b. Deploying ASP.NET Application to run with its own unique set of properties, create a unique application pool for that application . Note: You must be a member of the Administrators group on the local computer to perform the following procedures .As a security best practice, log on to your computer by using an account that is not in the administrators group, and then use the runas command to run IIS Manager as an administrator At a command prompt, type runas /user: Administrative_AccountName mmc%syste mroot%system32\inetsrv\iis.msc.

Step to create a new Application Pool : 1. In IIS Manger, expand the local computer, right-click
Application Pools, point to new and then click Application Pool. 2. In the application pool name box, type the new application tool. 3. If the ID that appears in the Application pool Id box is not the ID that you want, type a new ID. 4. Under Application pool setting, click the appropriate setting. If you click Use existing application tool as template, in the application pool name box, right click the application pool that you want to use as a template. 5. Click OK. Application pool allows you to apply configuration settings to group of applications and the worker processes that service those applications. Any web site, web directory, or virtual directory can be assigned to an application pool.

Assigning an application to an application pool:

In IIS Manager, right click the application that you want to assign to an application pool, and then click properties. Click the virtual directory, directory and home directory tab. If you are assigning a directory or virtual directory, verify that application name is filled in. If the application name box is not filled in, click create, and then type a name. In the application pool list box, click the name of the application pool to which you want to assign the web site.

About Configuring Servers for applications (IIS 6.0)

Internet information services (IIS) 6.0 delivers web hosting services through an adjustable architecture that you can use to manage server resources with improved stability, efficiency, and performance. IIS separates applications into isolated pools and automatically detects memory leaks, defective processes, and over utilized resources. When problems occur, IIS manages them by shutting down and redeploying faulty resources and connecting faulty processes to analytical tools. IIS can run in either of two mutually exclusive modes of operation: Worker process isolation mode. This is the default mode of IIS 6.0, isolates key components of the World Wide Web publishing service (WWW service) from the effects of errant applications, and it protects applications from each other by using the worker process component. Use worker process isolation mode unless you have a specific compatibility issue that makes the use of IIS 5.0 isolation mode necessary. Web sites that serve static content or simple ASP applications

should be able to move to IIS 6.0 running in worker process isolation mode with little or no modification. IIS 5.0 isolation mode. With this mode, you can run applications that are incompatible with worker process isolation mode because they were developed for earlier versions of IIS. Applications that run correctly on IIS 5.0 should run correctly on IIS 6.0 in IIS 5.9 isolation mode. Worker process isolation mode provides better default security for running web applications than IIS 5.0 isolation mode. By default, worker processes run with the Network service identity. The network service account has lower access rights than the default account for IIS 5.0 application mode run as local system. The local system account can read, execute, and change most of the resources on the computer. The default isolation mode upon installing IIS 6.0 depends on whether you perform a clean installation or an upgrade.

After a clean install of IIS 6.0, IIS runs in worker process isolation mode. After an upgrade from an earlier version of IIS 6.0, the isolation mode is the same as configured on the previouslyinstalled version of IIS 6.0. After an upgrade from IIS 5.0 or IIS 4.0, IIS 6.0 runs in IIS 5.0 isolation mode by default to maintain compatibility with your existing applications.

Worker Process Isolation Mode:

IIS 6.0 introduces worker process isolation mode, which runs all Web applications in an isolated environment. When you run IIS in worker process isolation mode, applications can be configured to run in separate application pools. Each application pool is a logical representation of a configurable worker process and links to the applications in the pool. Worker processes operate independently of each other, they can fail without affecting other worker processes. The pooling of applications protects applications from the effects of worker processes that support other application pools. In this way, applications are protected from each other. In worker process isolation mode, Hypertext Transfer Protocol (HTTP) requests are routed directly to an in-kernel application pool queue serving the configured application. Worker processes that serve an application pool pull the requests directly from the queue avoiding process-switching overhead. To further protect your WWW service, IIS 6.0 isolates critical World Wide Web publishing service (WWW service) components, such as the HTTP protocol stack (HTTP.sys) and WWW service Administration and monitoring, from the effects of third party code running in worker processes. HTTP.sys continues to process requests. Meanwhile, the WWW service detects that the worker process is unhealthy and shuts it down. If there is demand for a new worker process to serve requests (HTTP.sys has requests queued), the WWW service starts a new worker process to pick the queued request form HTTP.sys. Even though a worker process has failed, the WWW service continues to process requests and shields the user from experiencing a loss of service. IIS 6.0 worker process isolation mode delivers the following specific improvements over earlier versions of IIS:

 Robust Performance isolation prevents Web applications and Web sites from affecting each other or the WWW service. Reboots of the operating system and restarting of the WWW service are avoided. Self-Healing automated management provides auto restart of failed worker processes and periodic restart of deteriorating worker process. Scalability Web gardens allow more than one worker process to serve the same application pool. Process Affinity enables the connection of worker processes to specific processors on multi-CPU servers. Automated debugging the debugging feature enables the automatic assignment of failing worker processes to debugging tools. CPU limiting this monitoring feature enables controlling the amount of CPU resources that an application pool consumes in a configured amount of time.

B. Deploying ASP.NET Applications.-In Programmer's Guide for .NET -Chapter 3 Developing ASP.NET Application, we have created the ASP.NET application. The ASP.NET application can be run on the local Internet Information Server (IIS) but you may want to deploy the ASP.NET on other machines. Visual Studio .NET provides the feature to create the installer ASP.NET applications so you can install the application on other machines easily. In this chapter: Creating the Setup Project for ASP.NET Application Installing the Application

Creating the Setup Project for ASP.NET Application

You can download the example of the Programmer's Guide for .NET -Chapter 3 Developing ASP.NET Application and follow the steps below to create the setup file and install it.

1. Open the Chapter 3 example in the Visual Studio .NET. 2. Right Click Solution,select Add>New Project...from menu. 3. Select Setup and Deployment Project in Project Types,
and the select Setup Wizard in Templates. Type "web school system" for name. Click OK to create the Setup and Deployment Project. 4. The Setup Project Wizard is shown 5. Select Create a setup for a web application and then click Next >. 6. Select Primary output from webschoolsystem and Content Files from webschoolsystem, this option will help you to add all the DLL or EXE and ASP.NET file to the setup file. You must select a correct project for primary output in the solution. After that, click Finish. You also can click Next > to follow the wizard to add readme file to the setup file. 7. The Setup project is created in solution. 8. Open the File System (Setup) of the Setup project. Right click the Web Application Folder\bin Folder, select Add>File... to add the hibernate.cfg.xml manually from the DB-VA generated C# project. 9. Right click the Web School System Setup project and then select Build on menu.

10. The Setup File is created in the Web School System

Setup\Debug folder.

Installing the Application

The setup file for ASP.NET application is created. You can copy the Web School System Setup.msi file to other machines and install. The installation machine must have IIS installed otherwise the message below will be shown.

1. The setup wizard will be shown if your machine has IIS

installed. Click Next >. 2. Type the Virtual Directory name and Port for the web application. The Virtual Directory is the web application for browser to access. For example, http://localhost:<<Port>>/<<Virtual directory>>. 3. Confirm to install, then the application will be installed on your selected path. Click Close to finish the installation. 4. Open the Internet Information Service (IIS) Manager, you can see the ASP.NET application is installed on Web Sites\Default Web Site\<Virtual directory>. 5. Go to the http://localhost/webss/index.htm, the ASP.NET application is running in the IIS.

The End !