Summer 2012 Master of Computer Application (MCA) Semester 5 MC0081 .

(DOT) Net Technologies 4 Credits Assignment Set 1

1. Describe the following with respect to .Net: a. Features of .Net Platform b. Components of .Net Architecture c. Assemblies Overview (Ans) a)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: 1. The common language runtime and, 2. The .NET Framework class library. Common language runtime:

The common language runtime is the foundation of the .NET Framework. Runtime can be taken 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. .NET Framework class library:

It 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. The figure below 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.

Relationship between Common Language Runtime (CLR) and Class Library b) Components of .Net Architecture The major components of the .Net framework are shown in the figure below:

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. CLR includes a common system of data types. These common types plus a standard interface convention, make cross language inheritance possible. 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:

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. 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 the space is available in the memory heap, the runtime continues. But after one point, garbage collector is performed in order to free some space. Stack Walk: This concept is helpful to anyone interested in building a profiler to examine managed applications. The profiling API in version 2.0 of the CLR has a new method named DoStackSnapshotthat lets your profiler walk the call stack of the application you're profiling. The DoStackSnapshotmethod uses the same stack walker used by the garbage collector,

security system, exception system, and so on.DoStackSnapshotis well suited for sampling profilers. Class Loader: Normally, the Java Virtual Machine loads classes from the local file system in a platform-dependent manner. 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 defineClassconverts an array of bytes into an instance of class Class. Instances of this newly defined class can be created using the newInstancemethod 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 loadClassmethod 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 resolveClassmethod should be called. 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. 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. c) 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 My Type loaded in the scope of one assembly is not the same as a type called My Type 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 version able 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. Dynamic assemblies: are run directly from memory and are not saved to disk before execution. You can save dynamic assemblies to disk after they have executed.

Benefits of Assemblies: Assemblies are designed to simplify application deployment and to solve versioning problems that can occur with component-based applications. 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.

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

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.

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. 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.

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.

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

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. (Ans) 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 View State: The View State property of the control is populated. The View State 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 View State 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 View State, 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 To create the simple Web Form that will be used in the above example, go to the option start up Visual Studio .NET and open a New Project named ProgrammingCSharpWeb. Select the Visual C# Projects folder (because C# is your language of choice), select ASP.NET Web Application as the project type, and type in its name, ProgrammingCSharpWeb. Visual Studio .NET will display http://localhost/ as the default location, as shown in Figure

Figure: Creating a project in the New Project window of Visual Studio .NET Visual Studio places nearly all the files it creates for the project in a folder within your local machine's default web site for example, c:\Inetpub\wwwroot\ProgrammingCSharpWeb. The solution files and other Visual Studio-specific files are stored in <drive>\Documents and Settings\<user name>\My Documents\Visual Studio Projects (where <drive>and <user name>are specific to your machine). When the application is created, Visual Studio places a number of files in your project. The Web Form itself is stored in a file named WebForm1.aspx. This file will contain only HTML. A second, equally important file, WebForm1.aspx.cs, stores the C# associated with your form; this is the code-behind file. The code-behind file does not appear in the Solution Explorer. To see the code behind (.cs) file, you must place the cursor within Visual Studio .NET, right-click the form, and choose "View Code" in the pop-up menu. You can now tab back and forth between the forms itself, WebForm1.aspx, and the C# code-behind file, WebForm1.aspx.cs. When viewing the form, WebForm1.aspx, you can choose between Design mode and HTML mode by clicking the tabs at the bottom of the Editor window. Design mode lets you drag controls onto your form; HTML mode allows you to view and edit the HTML code directly. code-behind files: Start by renaming WebForm1.aspx to HelloWeb.aspx. To do this, close WebForm1.aspx,and then right-click its name in the Solution Explorer. Choose Rename and enter the name

HelloWeb.aspx. After renaming it, open HelloWeb.aspx and view the code; it is seen that codebehind file has been renamed as well to HelloWeb.aspx.cs.When you create a new Web Form application, Visual Studio .NET will generate a bit of boilerplate code to get you started, as shown below: <%@ Page language="c#" Codebehind="HelloWeb.aspx.cs" AutoEventWireup="false" Inherits="ProgrammingCSharpWeb.WebForm1" %> <! DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" > <html> <head> <title>WebForm1</title> <meta name="GENERATOR" Content="Microsoft Visual Studio 7.0"> <meta name="CODE_LANGUAGE" Content="C#"> <meta name="vs_defaultClientScript" content="JavaScript"> <meta name="vs_targetSchema" content="http://schemas.microsoft.com/intellisense/ie5"> </head> <body MS_POSITIONING="GridLayout"> <form id="Form1" method="post" runat="server"> </form> </body> </html>

Run the page by pressing Ctrl-F5 (or save it and navigate to it in your browser). The output will be somewhat like this:

3. Describe the following with respect to State Management in ASP.Net: a. Cookies in ASP.NET b. Session State c. Application State

(Ans) a)COOKIES IN ASP.NET Introduction: Cookies provide a means in Web applications to store user-specific information. For example, when a user visits your site, you can use cookies to store user preferences or other information. When the user visits your Web site another time, the application can retrieve the information it stored earlier. A cookie is a small bit of text that accompanies requests and pages as they go between the Web server and browser. The cookie contains information the Web application can read whenever the user visits the site. Cookies are associated with a Web site, not with a specific page, so the browser and server will exchange cookie information no matter what page the user requests from your site. As the user visits different sites, each site might send a cookie to the user's browser as well; the browser stores all the cookies separately. Cookies help Web sites store information about visitors. Generally, cookies are one way of maintaining continuity in a Web applicationthat is, of performing state management. Except for the brief time when they are actually exchanging information, the browser and Web server are disconnected. Each request a user makes to a Web server is treated independently of any other request. Many times, however, it's useful for the Web server to recognize users when they request a page. For example, the Web server on a shopping site keeps track of individual shoppers so the site can manage shopping carts and other user-specific information. A cookie therefore acts as a kind of calling card, presenting pertinent identification that helps an application know how to proceed. Cookies are used for many purposes, all relating to helping the Web site remember users. For example, a site conducting a poll might use a cookie simply as a Boolean value to indicate whether a user's browser has already participated in voting so that the user cannot vote twice. A site that asks a user to log on might use a cookie to record that the user already logged on so that the user does not have to keep entering credentials. Cookie Limitations: Most browsers support cookies of up to 4096 bytes. Because of this small limit, cookies are best used to store small amounts of data, or better yet, an identifier such as a user ID. Browsers also impose limitations on how many cookies your site can store on the user's computer. Most browsers allow only 20 cookies per site; if you try to store more, the oldest cookies are discarded. Some browsers also put an absolute limit, usually 300, on the number of cookies they will accept from all sites combined. Users can set their browser to refuse cookies. If you define a P3P privacy policy and place it in the root of your Web site, more browsers will accept cookies from your site.

However, you might have to avoid cookies altogether and use a different mechanism to store user-specific information. A common method for storing user information is session state, but session state depends on cookies, as explained later in the section "Cookies and Session State." Writing Cookies The browser is responsible for managing cookies on a user system. Cookies are sent to the browser via the HttpResponse object that exposes a collection called cookies. You can access the HttpResponse object as the Response property of your Page class. Any cookies that you want to send to the browser must be added to this collection. When creating a cookie, you specify a Name and Value. Each cookie must have a unique name so that it can be identified later when reading it from the browser. Because cookies are stored by name, naming two cookies the same will cause one to be overwritten. If you do not set the cookie's expiration, the cookie is created but it is not stored on the user's hard disk. Instead, the cookie is maintained as part of the user's session information. When the user closes the browser, the cookie is discarded. You can add cookies to the Cookies collection in a number of ways. The following example shows the method using C# code to write cookies: Response.Cookies ["userName"].Value = "patrick"; Response.Cookies ["userName"].Expires = DateTime.Now.AddDays (1); HttpCookieaCookie = new HttpCookie ("lastVisit"); aCookie.Value = DateTime.Now.ToString (); aCookie.Expires = DateTime.Now.AddDays (1); Response.Cookies.Add (aCookie); b)SESSION STATE ASP.NET session state enables you to store and retrieve values for a user as the user navigates the different ASP.NET pages that make up a Web application. HTTP is a stateless protocol, meaning that your Web server treats each HTTP request for a page as an independent request; by default, the server retains no knowledge of variable values used during previous requests. As a result, building Web applications that need to maintain some cross-request state information (applications that implement shopping carts, data scrolling, and so on) can be a challenge. ASP.NET session state identifies requests received from the same browser during a limited period of time as a session, and provides the ability to persist variable values for the duration of that session. ASP.NET session state is enabled by default for all ASP.NET applications. ASP.NET sessionstate variables are easily set and retrieved using the Session property, which stores session variable values as a collection indexed by name.

to be ASP.NET stores session information in the memory space of the ASP.NET application by default. We can optionally, store session information using a stand-alone service so that session information is preserved if the ASP.NET application is restarted, in a SQL Server so that session information is available to multiple Web servers in a Web farm (and also persists if the ASP.NET application is restarted), or in a custom data store. ASP.NET also provides several other options for persisting data within an application besides session state. Session Variables: Session variables are stored in a SessionStateItemCollection object that is exposed through the HttpContext: Session property. In an ASP.NET page, the current session variables are exposed through the Session property of the Page object. The collection of session variables is indexed by the name of the variable or by an integer index. Session variables are created by referring to the session variable by name. You do not have to declare a session variable or explicitly add it to the collection. The following example shows how to create session variables in an ASP.NET page for the first and last name of a user, and set them to values retrieved from TextBox controls. Session variables can be any valid .NET Framework type. Session Identifiers: Sessions are identified by a unique identifier that can be read by using the SessionID property. When session state is enabled for an ASP.NET application, each request for a page in the application is examined for a SessionID value sent from the browser. If no SessionID value is supplied, ASP.NET starts a new session and the SessionID value for that session is sent to the browser with the response. By default, SessionID values are stored in a cookie. However, you can also configure the application to store SessionID values in the URL for a "cookieless" session. A session is considered active as long as requests continue made with the same SessionID value. If the time between requests for a particular session exceeds the specified time-out value in minutes, the session is considered expired. Requests made with an expired SessionID value result in a new session. Session Modes: ASP.NET session state supports several storage options for session variables. Each option is identified as a session-state Mode type. The default behavior is to store session variables in the memory space of the ASP.NET worker process. However, you can also specify that session state should be stored in a separate process, in a SQL Server database, or in a custom data source. If you do not want session state enabled for your application, you can set the session mode to Off. Session Events: ASP.NET provides two events that help you manage user sessions. The Session_OnStart event is raised when a new session starts, and the Session_OnEnd event is raised when a session is abandoned or expires. Session events are specified in the Global.asax file for an ASP.NET application.

The Session_OnEnd event is not supported if the session Mode property is set to a value other than InProc, which is the default mode. Configuring Session State Session state is configured by using the sessionState element of the system.web configuration section. You can also configure session state by using the EnableSessionState value in the @ Page directive. The sessionStateelement enables you to specify the following options: The mode in which the session will store data. The way in which session identifier values are sent between the client and the server. The session Timeout value. Supporting values that are based on the session Mode setting.

The following example shows a sessionState element that configures an application for SQLServer session mode. It sets the Timeout value to 30 minutes, and specifies that session identifiers are stored in the URL. <sessionState mode="SQLServer" cookieless="true regenerateExpiredSessionId="true " timeout="30" SqlConnectionString="Data Source=MySqlServer;Integrated Security=SSPI;" stateNetworkTimeout="30"/> We can disable session state for an application by setting the session-state mode to off.

c)APPLICATION STATE Application state is a data repository available to all classes in an ASP.NET application. Application state is stored in memory on the server and is faster than storing and retrieving information in a database. Unlike session state, which is specific to a single user session, application state applies to all users and all sessions. Therefore, application state is a useful place to store small amounts of often-used data that does not change from one user to another. Using Application State: Application state is stored in an instance of the HttpApplicationState class. This class exposes a key-value dictionary of objects. The HttpApplicationState instance is created the first time a user accesses any URL resource in an application. The HttpApplicationState class is most often accessed through the Application property of the HttpContext class. Application can be used in two ways:

We can add, access, or remove values from the Contents collection directly through code. The HttpApplicationState class can be accessed at any time during the life of an application. Alternatively, we can add objects to the StaticObjects collection via an <object runat="server"> declaration in your Web application's Global.asax file. Application state defined in this way can then be accessed from code anywhere in your application. Application State Considerations: When using application state, you must be aware of the following important considerations: Resources: Because it is stored in memory, application state is very fast compared to saving data to disk or a database. However, storing large blocks of data in application state can fill up server memory, causing the server to page memory to disk. As an alternative to using application state, you can use the ASP.NET cache mechanism for storing large amounts of application data. The ASP.NET cache also stores data in memory and is therefore very fast; however, ASP.NET actively manages the cache and will remove items when memory becomes scarce. Volatility: As the application state is stored in server memory, it is lost whenever the application is stopped or restarted. For example, if the Web.config file is changed, the application is restarted and all application state is lost unless application state values have been written to a non-volatile storage medium such as a database. Scalability: Application state is not shared among multiple servers serving the same application, as in a Web farm, or among multiple worker processes serving the same application on the same server, as in a Web garden. Your application therefore cannot rely on application state containing the same data for application state across different servers or processes. If your application runs in multi-processor or multi-server environments, consider using a more scalable option, such as a database, for data that must preserve fidelity across the application. Concurrency: Application state is free-threaded, which means that application state data can be accessed simultaneously by many threads. Therefore, it is important to ensure that when you update application state data, you do so in a thread-safe manner by including built-in synchronization support. You can use the Lock and UnLock methods to ensure data integrity by locking the data for writing by only one source at a time.

4. Describe the following with respect to Web Services in .Net: a. Writing and Testing a Web Service b. Implementing a Web Service Client (Ans) a) WRITING AND TESTING A WEB SERVICE Writing a Web Service:

The ASMX file shown in Figure below. It implements two Web methods: Add and Subtract. Both take two integers as input and return an integer as well. Deploying the Web service is as simple as copying it to a directory on your Web server that is URL-addressable. If you put Calc.asmx in wwwroot, the Web services local URL is http://localhost/calc.asmx.

Calc.asmx demonstrates several important principles of Web service programming using the .NET Framework: Web services are implemented in ASMX files. ASMX is a special file name extension registered to ASP.NET (specifically, to an ASP.NET HTTP handler) in Machine.config. ASMX files begin with @ WebService directives. At a minimum, the directive must contain a Class attribute identifying the class that makes up the Web service. Web service classes can be attributed with optional WebService attributes. The one in this example assigns the Web service a name and a description that show up in the HTML page generated when a user calls up Calc.asmx in his or her browser. The WebService attribute also supports a Namespace parameter that can be used to change the name of the XML namespace that scopes the Web services members. Web methods are declared by tagging public methods in the Web service class with WebMethod attributes. You can build helper methods into a Web service methods that are used internally by Web methods but that are not exposed as Web methods themselves by omitting the attribute. The WebMethod attributes in Figure 8.5 also assign descriptive text to their Web methods. Youll learn more about Description and other WebMethod parameters in the section entitled The WebMethod Attribute. HTTP, XML, and SOAP are hidden under the hood.

Calc.asmx is a full-blown Web service when installed on a Web server outfitted with ASP.NET. Its Web methods can be invoked with SOAP, HTTP GET, and HTTP POST, and its capable of returning output in SOAP responses or simple XML wrappers. Testing a Web Service: For testing an ASMX Web service, call it in the browser. Copy Calc.asmx to wwwroot and type http://localhost/calc.asmxin the browsers address bar. User will be greeted as shown in the figure. 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.

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

Figure: Test page for the Add method

Figure: 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. b) IMPLEMENTING A WEB SERVICE CLIENTS: 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 (or the URL of a DISCO file that points to a WSDL contract). Web Service Proxies: The key concept to grasp when writing Web service clients is that of the Web service proxy. A Web service proxy is an object that provides a local representation of a remote Web service. A proxy is instantiated in the clients own application domain, but calls to the proxy flow through the proxy and out to the Web service that the proxy represents. The Wsdl.exe utility that comes with the .NET Framework SDK (and that is integrated into Visual Studio .NET) generates Web service proxy classes from WSDL contracts. The methods in the proxy class mirror the Web methods in the Web service. If the Web service exposes Web methods named Add and Subtract, the Web service proxy also contains methods named Add and Subtract. When you call one of these methods, the proxy packages up the input parameters and invokes the Web method using the protocol encapsulated in the proxy (typically SOAP). The proxy insulates you from the low-level details of the Web service and of the protocols that it uses. It even parses the XML that comes back and makes the result available as managed types. Simple Web Service Client: To write a client, following are the steps:

Use Wsdl.exe to create a proxy class for Calc.asmx. If you installed Calc.asmx in wwwroot, the proper command is wsdl http://localhost/calc.asmx Wsdl.exe responds by creating a file named Calculator Web Service.cs. Create a new text file named CalcClient.cs and enter the code in Figure.

Compile the CS files into a console application with the following command: cscCalcClient.cs "Calculator Web Service.cs" Run CalcClient.exe.

CalcClient.exe instantiates a Web service proxy and calls the services Add method. The resulting output proves beyond the shadow of a doubt that Calc.asmx is smart enough to add 2 and 2 CalcClient.cs using System; classMyApp { public static void Main () { CalculatorWebServicecalc = new CalculatorWebService (); int sum = calc.Add (2, 2); Console.WriteLine ("2 + 2 = " + sum); } }

Console client for Calc.asmx Avoiding Hard-Coded Service URLs:

Look through a CS file generated by Wsdl.exe, and youll see the Web service proxy class as well as the methods that wrap the Web services Web methods. Youll also see that the Web services URL is hardcoded into the CS file in the proxys class constructor.

Eg: publicCalculatorWebService() { this.Url = "http://www.wintellect.com/calc.asmx"; } If the Web service moves, youll have to modify the CS file and regenerate the proxy. To avoid having to update code when a Web services URL changes, you can use Wsdl.exes /appsettingurlkey (abbreviated /urlkey) switch. The command wsdl /urlkey:CalcUrl http://www.wintellect.com/calc.asmx produces the following class constructor: publicCalculatorWebService() { stringurlSetting = System.Configuration.ConfigurationSettings.AppSettings["CalcUrl"]; if ((urlSetting != null)) { this.Url = urlSetting; } else { this.Url = "http://www.wintellect.com/calc.asmx"; } }

Now you can assign a value to CalcUrl in the appSettings section of a local Web.config file, like so: <configuration> <appSettings> <add key="CalcUrl" value="http://www.wintellect.com/calc.asmx" /> </appSettings> </configuration>

If the URL changes, you can update the proxy simply by editing Web.config. No code changes are required

Summer 2012 Master of Computer Application (MCA) Semester 5 MC0081 . (DOT) Net Technologies 4 Credits Assignment Set 2

1. Write a program in C# language to perform the following operations: a. Basic arithmetic operations b. Finding greatest of n numbers Write separate programs for each of the above points. (Ans) a) BASIC ARITHMETIC OPERATION: using System; class MainClass { static void Main(string[] args) { int a,b,c,d,e,f; a = 1; b = a + 6; Console.WriteLine(b); c = b - 3; Console.WriteLine(c); d = c * 2; Console.WriteLine(d); e = d / 2; Console.WriteLine(e); f = e % 2; Console.WriteLine(f); } } b) FINDING GREATER OF N NUMBERS public static void FindLargestAndSmallest() { int arraySize; bool isNum; int largestNum;

int[] numArray = new int[50] //ask the user for the size of their array Console.WriteLine("Enter the size of Array"); //read in the value string sizeString = Console.ReadLine(); //we will now use TryParse to get the numeric value entered isNum = Int32.TryParse(sizeString, out arraySize); //now we will determine if the value is numeric if (isNum) { //then entered a numeric value so now we need to //ask for the values they want in their array Console.WriteLine("Enter array value:"); for (int i = 0; i < arraySize; i++) { //int variable to hold the our value from TryParse int temp; //read in each value and add it to our array if it's //a numeric value string arrayValue = Console.ReadLine(); isNum = Int32.TryParse(arrayValue, out temp);

//now do our check if (isNum) { //value is numeric soa dd to our array numArray[i] = temp; } else { //value isnt numeric Console.WriteLine("Array values must be numeric!"); break; } } Console.Write("\r\n"); //now we need to set the values of our largest largestNum = numArray[0]; //now loop through the length of our array for (int i = 1; i < arraySize; i++) { //check if the current array index is larger //than the largest number variable

if (numArray[i] > largestNum) { //if it is then that is the largest number //(for this iteration) largestNum = numArray[i]; } //now print out the results Console.WriteLine("Largest value is: {0}", largestNum); } else { Console.WriteLine("Array size must be numeric!"); } }

2. Explain the following with respect to ASP.Net: a. Master Pages b. Themes & Skins Write code snippets to demonstrate the above concepts. (Ans)

a) MASTER PAGES Master Pages The Master Pages feature provides the ability to define common structure and interface elements for your site, such as a page header, footer, or navigation bar, in a common location called a "master page", to be shared by many pages in your site. This improves the maintainability of your site and avoids unnecessary duplication of code for shared site structure or behavior. A Master Page is a page that contains markup and controls that should be shared across multiple pages in your site.For example, if all of your pages should have the same header and footer banners or the same navigation menu, you could define this in a Master Page once, and then all pages associated to this Master Page would inherit those common elements. The advantage of defining the header, footer, and navigation in a Master Page is that these elements need only be defined once, instead of multiple times in duplicate code across the pages in your site. In working with Master Pages, the developer creates a Master File that is the template referenced by a subpage or Content Page. Master Pages use a .master file extension, whereas content pages use the .aspx file extension you are used to; but content pages are declared as such within the files page directive. Master and Content Pages: Defining a Master Page is just like defining a normal page. Master Pages can contain markup, controls, or code, or any combination of these elements. However, a Master Page can contain a special type of control, called a ContentPlaceHolder control. A ContentPlaceHolder defines a region of the master page rendering that can be substituted with content from a page associated to the master. A ContentPlaceHolder can also contain default content, just in case the derive page does not need to override this content. The syntax of a ContentPlaceHolder control is given below: <%-- ContentPlaceHolder control --%> <asp:contentplaceholder id="FlowerText" runat="server"/> <%-- ContentPlaceHolder with default content --%> <asp:contentplaceholder id="FlowerText" runat="server"> <h3>Welcome to my florist website!</h3>

</asp:contentplaceholder> To differentiate a Master Page from a normal page, a Master Page is saved under the .master file extension. A page can derive from a Master Page by defining a MasterPageFile attribute on its Page directive, as demonstrated below. A page that is associated to a Master Page is called a Content Page. <%@ Page MasterPageFile="Site.master" %> A Content Page can declare Content controls that specifically override content placeholder sections in the Master Page. <%@ Page MasterPageFile="Site.master" %> <asp:content id="Content1" contentplaceholderid="FlowerText" runat="server"> With sunshine, water, and careful tending, roses will bloom several times in a season. </asp:content> <asp:content id="Content2" contentplaceholderid="FlowerPicture" runat="server"> <asp:Image id="image1" imageurl="~/images/rose.jpg" runat="server"/> </asp:content> The following example demonstrates the relationship between Master and Content pages. The Master Page in this case defines two ContentPlaceHolder regions, named FlowerPicture and FlowerText, along with some default content for those regions. Individual content pages in the site inherit the common site layout and look-and-feel from the Master Page, but override the default content for the named ContentPlaceHolder regions with their own content. Note that the Default.aspx page in this site does not define any Content controls, and so it just inherits the default content from the Master Page. b)THEMES AND SKINS Creating Themes: Themes and Skins: The Themes and Skins feature of ASP.NET allows you to factor style and layout information into a separate group of files, collectively called a Theme. A Theme can then be applied to any site to affect the look and feel of pages and controls within the site. Style changes to a site can then be easily maintained by making changes to the Theme, without having to edit the individual pages in your site. Themes can also be shared with other developers. When we build a web application, it usually has a similar look-and-feel across all its pages. Not too many applications are designed with each page dramatically different from each other. In general, the applications use similar fonts, colors, and server control styles across all the pages within the application. We can apply these common styles individually to each and every server control or objects on each page, or you can use a capability provided by ASP.NET to centrally specify these styles. All pages or parts of pages in the application can then access them.

Themes are the text-based style definitions in ASP.NET. We create .skin files in the Theme folder. A .skin file can contain one or more control skins for one or more control types. We can define skins in a separate file for each control or define all the skins for a theme in a single file. There are two types of control skins, default skins and named skins: A Default Skin automatically applies to all controls of the same type when a theme is applied to a page. A Control Skin is a default skin if it does not have a SkinID attribute. For example, if you create a default skin for a Calendar control, the control skin applies to all Calendar controls on pages that use the theme. (Default skins are matched exactly by control type, so that a Button control skin applies to all Button controls, but not to LinkButton controls or to controls that derive from the Button object.) A Named Skin is a control skin with a SkinID property set. Named skins do not automatically apply to controls by type. Instead, you explicitly apply a named skin to a control by setting the control's SkinID property. Creating named skins allows you to set different skins for different instances of the same control in an application. Cascading Style Sheets: A theme can also include a cascading style sheet (.css file). When you put a .css file in the theme folder, the style sheet is applied automatically as part of the theme. You define a style sheet using the file name extension .css in the theme folder. The following are the uses of ASP.NET Themes: They enable you to define visual styles for your Web Pages They also allow you to apply styles, graphics They allow you to apply the CSS files themselves to the pages of an application They can be applied at the application, page, or server control level.

Example: This example demonstrates the application of themes to a sample ASP.NET web page: An ASP Page that does not use themes <% Page Language = VB %> <html xmlns = http://www.w3.org/1999/xhtml> <head runat = server> <title>STLNET</title> </head> <body> <form id = form1 runat = server> <h1> St. Louis .NET User Group</h1><br /> <asp:Textbox ID = Textbox1 runat = server/><br />

<br /> <asp:Calendar ID = Calendar1 runat = server/><br /> <asp:Button ID = Button1 runat = server Text = Button /> </form> </body> </html> This simple page shows some default server controls, but which you can change with one of these new ASP.NET themes. Example: Applying a Theme to an Entire Application <?xml Version = 1.0> <configuration> <system.web> <pages theme = SmokeAndGlass> </ system.web> </configuration> By specifying the Theme in your web.config file, you need not define the theme again in the Page directive of your ASP.NET pages. This theme is applied automatically to each and every page within your application. In order to apply the theme to only a specific part of an application, make use of the <location/> element to specify the areas of the application for which the theme should be applied. Removing Themes from the Server Controls: Sometimes you want an alternative to the theme that has already been defined. As an example, to change the text box server control that you have been already working with by making its background black and using white text: <asp:Textbox ID = TextBox1 runat = server BackColor = #000000 ForeColor = #ffffff /> To apply a theme to your ASP.NET page but not to the Textbox control, use the EnableTheming property of the Textbox Server Control: <asp:Textbox ID = TextBox1 runat = server BackColor = #000000 ForeColor = #ffffff EnableTheming = false /> To turn off the theming property for multiple controls within a page, consider using the Panel Control (or any Container Control) to encapsulate a collection of controls and then set the EnableTheming attribute of theControl Panel to false. This disables the theming for each and every control within the panel.

3. Describe the following example Web services: a. Web Service Discovery DISCO b. Web Service Discovery UDDI a)WEB SERVICE DISCOVERY-DISCO Once a client has a WSDL contract describing a Web service, it has all the information it needs to make calls to that Web service. 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 known as UDDI. The former is a file-based mechanism for local Web service discovery that is, for getting a list of available Web services from DISCO files deployed on Web servers. The latter is a global Web service directory that is itself implemented as a Web service. UDDI is discussed in the next section. The DISCO (short for discovery) protocol is a simple one that revolves around XML-based DISCO files. The basic idea is that you publish a DISCO file on your 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. To advertiseWeb services, you can deploy the following DISCO file at a well-known URL on your server. The contractRef elements identify the URLs of the Web services WSDL contracts. URLs can be absolute or relative (relative to the directory in which the DISCO file resides). The optional docRef attributes identify the locations of documents describing the Web services, which, because of the self-documenting nature of Web services built with the .NET Framework, are typically the ASMX files 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" /> </discovery> We can write DISCO files for individual Web services and reference them in a master DISCO file using discoveryRef elements. Heres a 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" /> </discovery> A third option is to deploy a VSDISCO file 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 those subdirectories noted with exclude elements: <?xml version="1.0" ?> <dynamicDiscovery xmlns="urn:schemas-dynamicdiscovery:disco.2000-03-17"> <exclude path="_vti_cnf" /> <exclude path="_vti_pvt" /> <exclude path="_vti_log" /> <exclude path="_vti_script" /> <exclude path="_vti_txt" /> </dynamicDiscovery> b) WEB SERVICE DISCOVERY-UDDI UDDI is an abbreviation for Universal Description, Discovery, and Integration. Jointly developed by IBM, Microsoft, and Ariba and supportedby hundreds of other companies, UDDI is a specification for building distributed databases that enable interested parties to discover each others Web services. No one company owns the databases; anyone is free to publish a UDDI-based business registry. Operator sites have already been established by IBM and Microsoft and are likely to be the first of many such sites that will come on line in the future. UDDI sites are themselves Web services. They publish a pair of SOAP-based APIs: an inquiry API for inquiring about companies and their Web services and a publisher API for advertising a companys Web services. Anyone can call the inquiry API, but operator s ites typically limit the publisher API to registered members. At the time of this writing, Microsoft was beta testing a UDDI .NET SDK featuring managed wrapper classes that simplify interactions with UDDI business registries. Most developers will never deal with UDDI APIs directly. Instead, theyll use high-level tools such as Visual Studio .NET to query UDDI business registries and generate wrapper classes that allow them to place calls to the Web services that they find there. The actual placing of UDDI calls will be limited primarily to tools vendors and to clients that wish to locate and bind to Web services dynamically.

4. Describe the following with respect to Web site deployment in ASP.Net: a. Creating Application Pools (IIS 6.0) b. Deploying ASP.NET Applications (Ans) a) CREATING APPLICATION POOLS(IIS 6.0) When we run IIS 6.0 in worker process isolation mode, you can isolate different Web applications 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 a 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, applications in other application pools do not affect that application. By using an application pool, we can assign specific configuration settings to a worker process (or, in the case of a Web garden, to a set of worker processes) that service a group of applications. If another application fails because of the volume of requests that it receives, you can set the application pools worker process to recycle when the application exceeds a 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 applications remain available even when a worker process serving an application pool is recycled because of a faulty application. Configuring Application Pools in IIS 6.0 (IIS 6.0): This feature of IIS 6.0 is available only when running in worker process isolation mode. An application pool is a configuration that links one or more applications 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 problems caused by applications in other application pools. By creating new application pools and assigning Web sites and applications to them, you can make your server more efficient and reliable, as well as making your other applications always available, even when the worker process serving the new application pool has problems.

Guidelines for Creating Application Pools:

To isolate Web applications on a Web site from Web applications on other sites running on the same computer, create an individual application pool for each Web site. For enhanced security, configure a unique user account (process identity) for each application pool. Use an account with the least user rights possible, such as Network Service 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, separate the two versions into different application pools. This isolates the test version of the application. As a design consideration, if you want to configure an application to run with its own unique set of properties, create a unique application pool for that application.

At a command prompt, type runas /user:Administrative_AccountName "mmc %systemroot%\system32\inetsrv\iis.msc". Steps to create a new Application Pool: In IIS Manager, expand the local computer, right-click Application Pools, point to New, and then click Application Pool. In the Application pool name box, type the name of the new application pool. If the ID that appears in Application pool ID box is not the ID that you want, type a new ID. Under Application pool settings, click the appropriate setting. If you click Use existing application pool as template, in Application pool name box, right-click the application pool that you want to use as a template. Click OK.

Application pools allow you to apply configuration settings to groups 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, or Home Directory tab

If you are assigning a directory or virtual directory, verify that Application name is filled in. If the Applicationnamebox 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.

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 processes. 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 Deploying ASP.NET Applications in IIS 6.0 (IIS 6.0) Microsoft Windows Server 2003 includes support for ASP.NET applications and the Microsoft .NET Framework version 1.1 with the operating system installation. This chapter describes how to deploy ASP.NET applications on a newly installed server running Internet Information Services (IIS) 6.0. Version 1.1 of the .NET Framework is installed with Windows Server 2003. Most ASP.NET applications run without modification on version 1.1 of the .NET Framework. Deployment Process using IIS 6.0 :

The process for deploying new ASP.NET applications on a newly installed Web server requires no understanding of earlier versions of IIS or the .NET Framework. All the ASP.NET configuration sections in the Machine.config and Web.config files are configured the same way in IIS 6.0, except for the <processModel>section of the Machine.config file. When IIS 6.0 is configured to run in worker process isolation mode, some of the attributes in the <processModel>section of the Machine.config file are now in equivalent IIS 6.0 metabase properties. In addition, if your ASP.NET applications need to retain session state, you must configure IIS 6.0 to use the appropriate ASP.NET application sessionstate method. Depending on the method you select, you might need to configure the ASP.NET state service or Microsoft SQL Server to act as the repository for centralized state storage. The process for deploying ASP.NET applications in IIS 6.0 is shown in Figure 9.2.

Note: Before deploying your ASP.NET applications on a production server, perform the process outlined in this section on a test server that is configured identically to your production server. Deploy the Web Server Install Windows Server 2003. Install and configure IIS 6.0. Enable ASP.NET in the Web service extensions list.

Install ASP.NET Applications 1. Create Web sites and virtual directories for each ASP.NET application by doing the following: Create Web sites and home directories. Create virtual directories.

2. Copy ASP.NET application content to the Web server. 3. Enable common storage for ASP.NET session state by completing the following steps: Select the method for maintaining and storing ASP.NET session state. If you have decided to maintain session state with the ASP.NET state service, configure out-of-process session state with the ASP.NET state service. If you have decided to maintain session state with SQL Server, configure out-of-process session state with SQL Server. Configure encryption and validation keys. Configure ASP.NET to use the appropriate session state. Secure the ASP.NET session state connection string.

Complete the ASP.NET Application Deployment Ensure the security and availability of your ASP.NET applications. Verify that the ASP.NET applications were deployed successfully. Back up the Web server. Enable client access to your ASP.NET applications.

Deploying the Web Server (IIS 6.0) You must install the Web server before you can install your ASP.NET applications. In addition to installing Windows Server 2003, you must install and configure IIS 6.0 on the Web server. You must also enable ASP.NET so that the Web server can run ASP.NET applications.

Figure:Deploying the Web Server Installing Windows Server 2003 (IIS 6.0) The deployment process presented here assumes that you install Windows Server 2003 with the default options. If you use other methods for installing and configuring Windows Server 2003, such as unattended setup, your configuration settings might be different. Note: When you complete the installation of Windows Server 2003, Manage Your Server automatically starts. The deployment process assumes that you quit Manage Your Server, and then further configure the Web server in Add or Remove Programsin Control Panel.

Installing and Configuring IIS 6.0 (IIS 6.0) Because IIS 6.0 is not installed during the default installation of Windows Server 2003, the next step in deploying the Web server is to install and configure IIS 6.0. The deployment process presented here assumes that you install IIS 6.0 with the default options in Add or Remove Programs in Control Panel. If you use other methods for installing and configuring Windows Server 2003, such as Manage Your Server, the default configuration settings might be different. Install and configure IIS 6.0 by completing the following steps: Step 1: Install IIS 6.0 with only the essential components and services. As with installing Windows Server 2003, the primary concern when installing and configuring IIS 6.0 is to ensure that the security of the Web server is maintained. Enabling unnecessary components and services increases the attack surface of the Web server. You can help ensure that the Web server is secure by enabling only the essential components and services in IIS 6.0.

Step 2: If you want to manage the Web site content by using Microsoft FrontPage, install FrontPage 2002 Server Extensions from Microsoft on the Web server. Enabling ASP.NET in the Web Service Extensions List (IIS 6.0): After you install IIS 6.0, you need to enable ASP.NET. You can enable ASP.NET in Add or Remove Windows Components, which is accessible from Add or Remove Programs in Control Panel. When you enable ASP.NET by using this method, ASP.NET is also enabled in the Web service extensions list. If you enabled ASP.NET in this way, then you can continue to the next step in the deployment process. ASP.NET is not Enabled: ASP.NETmight not be enabled in the Web service extensions list if either of the following is true: You installed a version of the .NET Framework and ASP.NET (other than version 1.1) from a Web download or as part of an application such as the Microsoft Visual Studio .NET development tool. You disabled ASP.NET in the Web service extensions list because you were not running ASP.NET applications on an existing Web server.

If ASP.NET is not already enabled, view the Web service extensions list in IIS Manager and configure the status of the ASP.NET v1.1.4322 Web service extension to Allowed.

Installing ASP.NET Applications (IIS 6.0): After the Web server is deployed, you can install your ASP.NET applications. First, you must create a Web site and virtual directories for each ASP.NET application. Then you need to install each ASP.NET application in the corresponding Web site and virtual directory. When there are provisioning or setup scripts for your ASP.NET applications, use these scripts to install the ASP.NET applications on the Web server. Because the provisioning and setup scripts create the Web sites and virtual directories while installing ASP.NET applications, you do not need to perform any manual steps to install the ASP.NET applications. In this case, run the provisioning or setup scripts to install and configure the Web sites and applications, and then continue to the next step in the application deployment process.

Installation Process for ASP.NET Applicatio Creating Web Sites and Virtual Directories for each ASP.NET Application (IIS 6.0): For each ASP.NET application, you must create a virtual directory in a new or existing Web site. Later in the installation process, you will install your ASP.NET applications into their corresponding Web sites and virtual directories. Create the Web sites and virtual directories for your ASP.NET applications by completing the following steps: Create Web sites and home directories. Create virtual directories

Creating Web Sites and Home Directories Using IIS 6.0 Each Web site must have one home directory. The home directory is the central location for your published Web pages. It contains a home page or index file that serves as a portal to other pages in your Web site. The home directory is mapped to the domain name of the Web site or to the name of the Web server. Create a Web site and home directory for an ASP.NET application by completing the following steps: Step 1: Create the folder that will be the home directory for the Web site on the Web server. The folder that is the home directory of the Web site contains all of the content and subdirectories for the Web site. The folder can be created on the same computer as the Web server or on a Universal Naming Convention (UNC)shared folder on a separate server. At a minimum, create the folder on the following:

An NTFS file system partition, which helps ensure proper security.

A disk volume other than the system volume, which reduces the potential of an attack on a Web site bringing down the entire Web server and improves performance. In a location that will not require requests for Web site content to contain /bin in the requested URL. As a security measure, ASP.NET returns a 404 error for all requests containing /bin in the requested URL.

Step 2: Create the Web site on the server. Step 3: If the Web site is FrontPage extended, then configure the Web site on the Web server to be FrontPage extended. Creating Virtual Directories (IIS 6.0) : A virtual directory is a folder name, used in an address, which corresponds to a physical directory on the Web server or a Universal Naming Convention (UNC) location. This is also sometimes referred to as URL mapping. Virtual directories are used to publish Web content from any folder that is not contained in the home directory of the Web site. When clients access content in a virtual directory, the content appears to be in a subdirectory of the home directory, even though it is not. For security reasons, you might want to move the Web site content to a different disk volume during the application deployment process. You can move the content to another disk volume on the Web server or to a shared folder on a separate server. You can use virtual directories to specify the UNC name for the location where the content is placed, and provide a user name and password for access rights. For each virtual directory required by the ASP.NET application, create a corresponding virtual directory on the Web server by completing the following steps : Create the folder on the Web server to contain the virtual directory content. 1. Ensure that you create the folder in a secure manner that does not compromise the security of the Web server. 2. Create the virtual directory under the appropriate Web site on the server.

Copying ASP.NET Application Content (IIS 6.0) : When no installation program or provisioning scripts exist for your ASP.NET application, you can copy the content of the ASP.NET application to the corresponding Web site and virtual directories that you created on the Web server. You can copy the ASP.NET application content to the Web server by using one of the following methods:

Run the Xcopycommand to copy ASP.NET application content to the Web server on an intranet or internal network. Use Microsoft Windows Explorer to copy ASP.NET application content to the Web server on an intranet or internal network. Use the Copy Project command in Visual Studio .NET to copy ASP.NET application content to the Web server on an intranet or internal network, if the application has been developed by using Visual Studio .NET.

Note: FrontPage Server Extensions must be installed on the Web server to use the Copy Project command. Use the Publish Web command in FrontPage to copy ASP.NET application content to the Web server on an intranet or over the Internet, if the Web site that contains the application has been developed using FrontPage.

Enabling Common Storage for ASP.NET Session State (IIS 6.0) : ASP.NET session state lets you share client session data across all of the Web servers in a Web farm or across different worker processes or worker process instances on a single Web server. Clients can access different servers in the Web farm across multiple requests and still have full access to session data. You can enable common storage for ASP.NET session state by performing the following steps: 1. Select the method for maintaining and storing ASP.NET session state. 2. If you have decided to maintain session state with the ASP.NET state service, configure outof-process session state with the ASP.NET state service.

3. If you have decided to maintain session state with SQL Server, configure out-of-process session state with SQL Server. 4. Configure the encryption and validation keys. 5. Configure ASP.NET to use the session state method that you selected in Step 1. 6. Secure the ASP.NET session state connection string in the registry