Professional Documents
Culture Documents
At the lowest level, the framework starts with Memory Management and Component Loading and goes all the way up to multiple ways of rendering user and program interfaces. The middle layer provides any system level capability that a developer needs. The base to the Framework is the Common Language Runtime (CLR). The CLR is the heart of the .Net framework, the engine that drives the key functionality. For example the CLR includes a common system of data types. These common types plus a standard interface convention, make cross language inheritance possible. The CLR also does the reference counting for objects and handles garbage collection. The middle layer consists of standard system services such as ADO.NET AND XML.
initially calls must be present. Other assemblies, such as localization resources or assemblies containing utility classes, can be retrieved on demand. This allows applications to be kept simple and thin when first downloaded. For more information about deploying assemblies, see Deploying Applications. It is the unit at which side-by-side execution is supported. For more information about running multiple versions of an assembly, see Assemblies and Side-by-Side Execution.
Assemblies can be static or dynamic. Static assemblies can include .NET Framework types (interfaces and classes), as well as resources for the assembly (bitmaps, JPEG files, resource files, and so on). Static assemblies are stored on disk in portable executable (PE) files. You can also use the .NET Framework to create dynamic assemblies, which are run directly from memory and are not saved to disk before execution. You can save dynamic assemblies to disk after they have executed. There are several ways to create assemblies. You can use development tools, such as Visual Studio 2005, that you have used in the past to create .dll or .exe files. You can use tools provided in the Windows Software Development Kit (SDK) to create assemblies with modules created in other development environments. You can also use common language runtime APIs, such as Reflection.Emit, to create dynamic assemblies. Benefits of Assemblies Assemblies are designed to simplify application deployment and to solve versioning problems that can occur with component-based applications.
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">
Output generated by the HelloWorld.aspx file 3. Describe the following with respect to State Management in ASP.Net: a. Cookies in ASP.NET b. Session State c. Application State
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: 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.
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 WebService attribute appear at the top of the page. Underneath is a list of Web methods that the service exposes, complete with the descriptions spelled out in the WebMethod attributes.
Calc.asmx as seen in Internet Explorer Click Add near the top of the page, and ASP.NET displays a page that you can use to test the Add method (Figure 8.7). ASP.NET knows the method name and signature because it reads them from the metadata in the DLL it compiled from Calc.asmx. It even generates an HTML form that you can use to call the Add method with your choice of inputs. Type 2 and 2 into the a and b boxes and click Invoke. The XML returned by the Web method appears in a separate browser window
A Sample Web Page The source code for the above web page using C# is given below: <%@ master language="C#" %> <html> <head> <link rel="stylesheet" href="StyleSheet.css" type="text/css" /> </head> <body> <form id="Form1" runat="server">
Nesting Master Pages The following is the code for the Home Page of the Nested Pages: <%@ page language="C#" MasterPageFile="~/Site4.master" %> 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: They enable you to define visual styles for your Web Pages
Page with theme applied: The App_Themes Folder Themes reside in the App_Themes folder directly under the application root directory. A Theme consists of a named subdirectory under this folder that contains a collection of one or more Skin files, named with the .skin extension. A Theme can also contain a CSS file and/or subdirectories for static files like images. The figure below shows an App_Themes directory with two Themes defined, named "Default" and "White", each of which has a single skin file and CSS file.
App_Themes Folder Observe in the previous example that the contents of a skin file are simply control definitions as they might appear in a page. A skin file can contain multiple control definitions, for example one definition for each control type. The properties of controls defined in the theme automatically override the local property value for a control of the same type in the target page with the Theme applied. For example, a <asp:Calendar Font-Name="Verdana" runat="server"/> control definition in a skin file will cause all Calendar controls in pages with the Theme applied to use the Verdana font. A local value for this property on the control will be overridden by the Theme. Note that it is an error to specify an ID property value for a control definition in a skin file. Global and Application Themes A Theme can reside at the application-level or machine-level (globally available to all applications). Applicationlevel Themes are placed in the App_Themes directory under the application root directory, as described above. Global Themes are placed in a "Themes" directory under an ASP.NETClientFiles folder under the ASP.NET installation directory, for example %WINDIR%\Microsoft.NET\Framework\<version>\ASP.NETClientFiles\Themes. The location of global themes is Inetpub\ wwwroot\aspnet_ client\system_web\<version>\Themes for IIS web sites. Assigning a Theme to a Page An individual page can be assigned a Theme by setting the <%@ Page Theme="..." %> directive to the name of a global or application-level Theme (the name of a folder under the Themes or App_Themes directory). A page can only have one Theme applied, but there may be multiple skin files in the theme that apply style settings to controls in the page. 3. Describe the following example Web services:
lications that are incompatible with worker process isolation mode because they were developed for earlier versions of IIS. Applications that run correctly on IIS 5.0 should run correctly on IIS 6.0 in IIS 5.0 isolation mode.
Worker process isolation mode provides better default security for running Web applications than IIS 5.0 isolation mode. By default, worker processes run with the Network Service identity. The Network Service account has lower access rights than the default account for IIS 5.0 isolation mode. Web applications that run in-process in IIS 5.0 application mode run as LocalSystem. The LocalSystem account can read, execute, and change most of the resources on the computer. The default isolation mode upon installing IIS 6.0 depends on whether you perform a clean installation or an upgrade. After a clean install of IIS 6.0, IIS runs in worker process isolation mode. After an upgrade from an earlier version of IIS 6.0, the isolation mode is the same as configured on the previously-installed version of IIS 6.0. After an upgrade from IIS 5.0 or IIS 4.0, IIS 6.0 runs in IIS 5.0 isolation mode by default to maintain compatibility with your existing applications. Worker Process Isolation Mode IIS 6.0 introduces worker process isolation mode, which runs all Web applications in an isolated environment. When you run IIS in worker process isolation mode, applications can be configured to run in separate application pools. Each application pool is a logical representation of a configurable worker process and links to the applications in the pool. Worker processes operate independently of each other; they can fail without affecting other worker processes. The pooling of applications protects applications from the effects of worker processes that support other application pools. In this way, applications are protected from each other. In worker process isolation mode, Hypertext Transfer Protocol (HTTP) requests are routed directly to an in-kernel application pool queue serving the configured application. Worker processes that serve an application pool pull the requests directly from the queue, avoiding process-switching overhead. To further protect your WWW service, IIS 6.0 isolates critical World Wide Web Publishing Service (WWW service) components, such as the HTTP protocol stack (HTTP.sys) and WWW Service Administration and Monitoring, from the effects of third-party code running in worker processes. HTTP.sys receives and queues requests for WWW services. When a worker process enters an unhealthy state, and thus stops processing requests, HTTP.sys continues to process requests. Meanwhile, the WWW service detects that the worker process is unhealthy and shuts it down. If there is demand for a new worker process to serve requests (HTTP.sys has requests queued), the WWW service starts a new worker process to pick up the queued requests from HTTP.sys. Even
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.
Deploying Your 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. 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 64bit 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: Install Windows Server 2003, which includes version 1.1 of the .NET Framework, with the default options. Install IIS 6.0 with the default settings in 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: 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: 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-of-process 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 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. below illustrates the process for deploying the Web server.
Installation Process for ASP.NET Applications 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 Xcopy command 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.