Master of Computer Application (MCA) Semester 5 MC0081 .

(DOT) Net Technologies (Book ID: B0974)

Assignment Set 1

1. Describe the steps involved in creating classes and objects with the help of a program in C#. 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... } EXAMPLE public 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 3 Console.WriteLine("Press any key to exit."); Console.ReadKey(); } } /* Output:unknownJohn Smith*/

2. Describe the following with respect to creating Web Forms in .Net environment: 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 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 Post back 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 Write programs with corresponding output screens to demonstrate the above concepts. To create the simple Web Form that will be used in the next example, 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

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>andappear 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 form 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. Let's take a closer look at the .aspx and code-behind files that Visual Studio creates. 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 you rename it, open HelloWeb.aspx and view the code; you will find that the code-behind 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 in Example 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>

What you see is typical boilerplate HTML except for the first line, which contains the following ASP.NET code: <%@ Page language="c#" Codebehind="HelloWeb.aspx.cs" AutoEventWireup="false" Inherits="ProgrammingCSharpWeb.WebForm1" %>

The language attribute indicates that the language used on the code-behind page is C#. The Codebehind attribute designates that the filename of that page is HelloWeb.cs, and the Inherits attribute indicates that this page derives from WebForm1. WebForm1 is a class declared in HelloWeb.cs. public class WebForm1 : System.Web.UI.Page As the C# code makes clear, WebForm1 inherits from System.Web.UI.Page, which is the class that defines the properties, methods, and events common to all server-side pages. Returning to the HTML view of HelloWeb.aspx, you see that a form has been specified in the body of the page using the standard HTML form tag: <form id="Form1" method="post" runat="server"> Web Forms assumes that you need at least one form to manage the user interaction, and creates one when you open a project. The attribute runat="server" is the key to the serverside magic. Any tag that includes this attribute is considered a server-side control to be executed by the ASP.NET framework on the server. Having created an empty Web Form, the first thing you might want to do is add some text to the page. By switching to HTML view, you can add script and HTML directly to the file just as you could with classic ASP. Adding the following line to the body segment of the HTML page will cause it to display a greeting and the current local time: Hello World! It is now <% = DateTime.Now.ToString( ) %> The <% and %> marks work just as they did in classic ASP, indicating that code falls between them (in this case, C#). The = sign immediately following the opening tag causes ASP.NET to display the value, just like a call to Response.Write( ). You could just as easily write the line as: Hello World! It is now <% Response.Write(DateTime.Now.ToString( )); %> Run the page by pressing Ctrl-F5 (or save it and navigate to it in your browser). You should see the string printed to the browser, as in Figure

Output generated by the HelloWorld.aspx file

3. Describe the following with respect to State Management in ASP.Net: a. Cookies in ASP.NET A cookie is a small amount of data that is stored either in a text file on the client file system or inmemory in the client browser session. It contains site-specific information that the server sends to the client along with page output. Cookies can be temporary (with specific expiration times and dates) or persistent.

You can use cookies to store information about a particular client, session, or application. The cookies are saved on the client device, and when the browser requests a page, the client sends the information in the cookie along with the request information. The server can read the cookie and extract its value. A typical use is to store a token (perhaps encrypted) indicating that the user has already been authenticated in your application. Note: The browser can only send the data back to the server that originally created the cookie. However, malicious users have ways to access cookies and read their contents. It is recommended that you do not store sensitive information, such as a user name or password, in a cookie. Instead, store a token in the cookie that identifies the user, and then use the token to look up the sensitive information on the server. b. Session State ASP.NET allows you to save values by using session state which is an instance of the HttpSessionState class for each active Web-application session. 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 will have a different session state. In addition, if a user leaves your application and then returns later, the second user session will have a different session state from the first. Session state is structured as a key/value dictionary for storing session-specific information that needs to be maintained between server round trips and between requests for pages. You can use session state to accomplish the following tasks: -device requests and map them to an individual session instance on the server. -specific data on the server for use across multiple browser or client-device requests within the same session. ing these events. Once you add your application-specific information to session state, the server manages this object. Depending on which options you specify, session information can be stored in cookies, on an out-ofprocess server, or on a computer running Microsoft SQL Server. c. Application State ASP.NET allows you to save values using application state which is an instance of the HttpApplicationState class for each active Web application. Application state is a global storage mechanism that is accessible from all pages in the Web application. Thus, application state is useful for storing information that needs to be maintained between server round trips and between requests for pages. Application state is stored in a key/value dictionary that is created during each request to a specific URL. You can add your application-specific information to this structure to store it between page requests. Once you add your application-specific information to application state, the server manages it.

4. Describe the following with respect to Web Services in .Net: a. Writing and Testing a Web Service

b. Implementing a Web Service Client

The ASMX file shown in Figure 8.5 is a complete Web service. 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: ed in ASMX files. ASMX is a special file name extension registered to ASP.NET (specifically, to an ASP.NET HTTP handler) in Machine.config. attribute identifying the class that makes up the Web service. 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. 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. data or SOAP messages because the .NET Framework deals with them for you.

Calc Web service Despite its brevity, 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. All we need now is a way to test it out. The .NET Framework lends a hand there too.

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 Web Service 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 Web Method 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

Test page for the Add method

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.

Implementing Web Service Clients 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 (or the URL of a DISCO file that

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.

2. Explain the following with respect to ASP.Net: a. Master Pages b. Themes & Skins Write code snippets to demonstrate the above concepts. 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. Just as Themes and Skins allow you to factor out style definitions from your page code and maintain them in a common file, Master Pages do the same for page layout. 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. The Master Pages are an easy way to provide a template that can be used by any number of ASP.NET pages in your application. 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.

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.

Themes & Control 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 you 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, your applications use similar fonts, colors, and server control styles across all the pages within the application. You 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. You create .skin files in the Theme folder. A .skin file can contain one or more control skins for one or more control types. You 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:

pplied 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. You can instantly change the appearance of this page without changing the style of each server control on the page. From within the Page directive, you simply apply an ASP.NET theme that you have either built or downloaded from the Internet: <%@ Page Language = VB Theme = SmokeAndGlass %> Adding the Them attribute changes the appearance of everything on the page that is defined in an example SmokeAndGlass theme file. If you have multiple pages, you do not have to think about applying styles to everything you do as you build because the styles are already defined centrally for you.

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 Creating Application Pools (IIS 6.0) When you 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, you can assign specific configuration settings to a worker process (or, in the case of a Web garden, to a set of worker processes) that services a group of applications. For example, you can configure worker process recycling, which offers several configuration options to match the needs 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 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. Guidelines for Creating Application Pools computer, create an individual application pool for each Web site. 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. server with the production version of the application, separate the two versions into different application pools. This isolates the test version of the application. 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 procedure or 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 %systemroot%\system32\inetsrv\iis.msc". Steps to create a new Application Pool: 1. In IIS Manager, 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 name of the new application pool. 3. If the ID that appears in Application pool ID box is not the ID that you want, type a new ID. 4. 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. 5. 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.

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. Overview of Deployment process using IIS 6.0

ASP.NET is a unified Web application platform that provides services to help you build and deploy enterprise-class Web applications and XML-based Web services. ASP.NET is supported on the Microsoft Windows Server 2003, Standard Edition; Windows Server2003, Enterprise Edition; Windows Server2003, Datacenter Edition; and Windows Server2003, Web Edition operating systems. ASP.NET is installed with the Microsoft .NET Framework version 1.1 as a part of Windows Server 2003. However, to run ASP.NET applications, you must also install IIS 6.0. ASP.NET is not available on the following operating systems: Microsoft Windows XP 64-Bit Edition; the 64-bit version of Windows Server 2003, Enterprise Edition; and the 64-bit version of Windows Server 2003, Datacenter Edition. The deployment process presented in this section describes how to deploy ASP.NET applications on a newly installed IIS 6.0 Web server. Before you begin this process, complete the following steps: options. Add or Remove Programs in Control Panel. When you configure IIS 6.0 to run in IIS 5.0 isolation mode, the settings in the <processModel> section of the Machine.config file are configured in the same way as they were in IIS 5.0 in the Machine.config or Web.config files. Upon completing the process described in this section, you will have a Web server running IIS 6.0 and hosting your ASP.NET applications. However, you can further configure the Web server to improve the security and availability of your ASP.NET applications. 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 session state 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

Deploying ASP.NET Applications in IIS 6.0 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 1. Install Windows Server 2003. 2. Install and configure IIS 6.0. 3. 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:

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