Release Date: 10/18/2004
| Update Date: 10/18/2004
Jayesh Patel, Bryan Acker, Robert McGOvernInfusion Developments
Suitable for: Microsoft ASP.NET 2.0INTERNET INFORMATION SERVICES 6.0.NET Framework 2.0
Summary: Discussion ASP.NET 2.0, Microsoft Internet Information Services 6.0 and Microsoft .NET Framework 2.0 are how to deploy, configure, monitor, and maintain web applications easier than before. Provide an overview for how to perform IT operations using ASP.NET 2.0 and IIS 6.0.
This page
Introduction Deployment Enhanced Code Hidden Model Compilation Option Update Application IIS Configuring Application Reliability Currently in XML Metal Database Management Web Application Monitoring .NET Application Detector Visualization Unicode Conversion Format: 8 Log Recording Performance Counter Event Tracking
Introduction
Microsoft ASP.NET 2.0 provides a number of new features that reduce the time required to generate a powerful and complex web application. However, generating an application is only part of the process. Once the site is established, you must deploy, monitor and maintain it in the life of the application. ASP.NET 2.0, Microsoft Internet Information Services (IIS) 6.0 and Microsoft .NET Framework 2.0 solves these problems with several new features that make the web application deployment, configuration, monitoring, and maintenance easier than before.
For example, the new compilation option allows you to deploy ASP.NET applications safely on a production server. Once the deployment is completed, the application cannot be changed until fully deployed. In another case, you may need a fully open deployment where you can change the source code or web page on the production server. An replaceable compilation option set can also be used to support this situation. The best thing is that any changes will be automatically reflected in the production application.
In terms of configuration, ASP.NET 2.0 provides a built-in management web site that allows you to create and configure users, configure data providers, and perform other management options over a secure web interface.
Finally, in terms of monitoring, ASP.NET 2.0 extends available monitoring in ASP.NET 1.x and provides better support for site counters, tracking, debugging, and health monitoring.
The new features in ASP.NET 2.0 are combined with IIS 6.0 (ASP.NET 2.0 and IIS 5.0 can also be used together), providing a lot of options for deployment, configuration, and monitoring your web application. Whether you are a professional system administrator, or build a small Web site, this article will provide you with the reliable overview of how to perform IT operations with ASP.NET 2.0 and IIS 6.0.
Back to top
deploy
ASP.NET 1.x and .NET Framework introduced several new mechanisms for deploying web applications. Compared to the ASP deployment, the most worthless of the best note is:
•
No need to register. In ASP, any external DLL must be registered in the Windows Registry. This registration requires careful management of GUID to avoid compatibility issues. The .NET application uses a different model to store the code, it does not depend on the Windows registry or the GUID identifier.
•
No need to restart. In ASP, if the developer updates a DLL, the site administrator has to stop and restart the IIS instance to get the changed code. Due to the process of processing models of ASP.NET, the code change will be automatically monitored and loaded without IIS restart. •
More deployment options. Deploying an ASP application requires several configuration steps, including the creation of the virtual directory, and registration of several components. On the other hand, ASP.NET applications can be deployed in several different mechanisms depending on the target and desired deployment type.
In this article, we have to see why ASP.NET 2.0 is different from ASP.NET 1.0 and show how to deploy ASP.NET 2.0 applications at each stage of its life cycle.
For development deployment
Microsoft Visual Studio 2005 includes a lightweight web server for developing ASP.NET applications. This web server can only serve the local request, so it is perfect for development. By using this built-in web server, you no longer need to use IIS on the development machine. You can use built-in servers and get full debugging support, without having to open any development code, and will not result in increased management maintenance work. Another important advantage is to use Visual Studio 2005, any user can generate and test applications. You no longer need to be administrators on the computer. It should be noted that the final application must still be deployed on IIS.
For product deployment
ASP.NET 2.0 applications must be deployed on a server with IIS 5.0 or version 6.0. In this article, we will focus on deploying to IIS 6.0.
Deploy .NET FRAMEWORK 2.0
In order to deploy ASP.NET 2.0 applications, you must first deploy .NET Framework 2.0 on the server. Fortunately, the .NET Framework is designed to make different versions on the same server. In other words, you can deploy the .NET Framework version 2.0, without uninstalling or modifying any apps using any version of Framework 1.x.
IIS MMC Management Unit
ASP.NET 2.0 deploys a special Microsoft Management Console (MMC) management unit deploying IIS, which allows you to decide which applications should use .NET Framework.
Figure 1. MMC display of the ASP.NET application
The MMC IIS tab allows you to choose which version of ASP.NET for your application and display the location of Web.config.
In addition to managing the Framework version, the console has a "Edit Configuration" button that allows you to edit most of the web.config settings without having to manipulate the web.config xml file. As an administrator, you will find that this MMC snap-in provides a very useful tool for configuring and managing multiple ASP.NET applications on a single server.
Back to top
Enhanced code hidden model
The traditional ASP page contains two types of design (HTML) and logic. If there is no feature-rich debugging environment, debugging and encoding readability will become more difficult as the number of code increases. The code hidden model separates the design from logic aspect.
The code hidden feature is first introduced in ASP.NET 1.x. This model separates the design of your page from logic, but there are several problems that appear with this model. The code hidden class is not automatically compiled at runtime, so the project is regenerated after each update. This model has caused the fragility of the code due to the pre-programming method, and the potential possibility of mismatch and synchronous errors is high.
The new code hidden model utilizes a local class. The partial class allows you to define different parts of the class in more than one file. These files are combined when compiling. ASP.NET 2.0 eliminates control declarations and allows Web forms and code hidden classes to be compiled at runtime. Back to top
Compile option
ASP.NET 2.0 provides four different compilation models for web applications:
•
Normal (ASP.NET 1.x). In a general ASP.NET web application, the code hidden file is compiled into a program set and stored in the / bin directory. The web page (ASPX) is compiled when needed. For most Web sites, this model can run normally. However, the compilation process makes it slower than the first request for any ASP.NET page. ASP.NET 2.0 continues to support this compilation mode.
•
Batch compilation. In ASP.NET 2.0, you can request a batch of applications through a single URL request. Just like ASP.NET 1.x, batch compilation eliminates the latency of the first page request, but has caused longer start cycle time. In addition, batch compilation still requires code hidden files to compile after pre-deployment.
•
Deploy pre-compilation. A new feature of ASP.NET 2.0 allows you to fully compile the project before deployment. In fully compiled, depending on the size and compilation settings of the application, all code hidden files, ASPX pages, HTML, graphics resources, and other backend code are compiled into one or more executable assembly. These assessments contain the entire Web site (except for web.config). This compilation method provides best performance and security for all functions for modifying the WEB site POST deployment. If you are dealing with high visible or highly secure Web sites, this option is the best choice for final deployment. However, if you are building a small site running on the local intranet, and the site is often changed, fully precompiled may be overkill.
•
Compiled with complete runtime. On the other extreme, ASP.NET 2.0 provides a new mechanism to compile the entire application at runtime. That is to say, you can put uncharacter-hidden files and any other associated code in the new / code directory, and let ASP.NET 2.0 go to create and maintain assemblies that will be generated from these files at runtime. Quote. This option provides best flexibility in changing the content of Web site content in the server.
Choosing the best compilation option will depend on your exact environment and needs. However, the compilation model maintains flexibility. Even if you choose to use the / code directory to store your code hidden file, you can still deploy your application with a fully compiled method.
For more information on compilation model, see ASP.NET 2.0 Internals.
Restriction recompilation
A compact feature of ASP.NET 2.0 is that the ASP.NET runtime will only be recompiled on an application before restarting the entire application. Basically, after running, after a certain amount of recompile, the ASP.NET runtime determines that the entire application may not be effective. The run library automatically closes the application instance and reloads the entire application without risking the risk of an error.
As a system administrator, you should never worry about this process because it is transparent and automated. The only concern is whether the application maintains a session. If you have configured your application to use an "out-state" process or database, it will also automatically maintain the event even if the application is restarted.
You can configure Allowed Ratio by adjusting the NumRecompilesBeforeAppRestart attribute attribute attribute attribute attribute at the mark of the web.config or machine.config file.
Deploy application
There are several ways to manually install the ASP.NET application. Two preferred methods are:
•
Xcopy. Xcopy deployment allows you to copy the .NET application file from a computer to another. For independent applications, this method is the fastest and easiest deployment option. Xcopy is the most effective in developing, testing, and in some web applications. However, the XCOPY method cannot be used with the global assembly cache (GAC), or an application for registration or configuration on the target computer. In the web application, if a virtual directory is created on the production server, Xcopy will be extremely effective. The term Xcopy refers to a DOS command that performs a lot of file transfer. •
Microsoft Windows Installer (MSI). In order to automate the virtual directory settings and allow repeated deployment, many administrators prefer traditional installations. Although MSI is available before .NET, Visual Studio provides a simplified tool for the .NET application with a quick creating MSI file. Your MSI file can generate a code access security policy on the target computer, create a desktop icon, and menu item, insert the registry key, and allow the easing for the .NET application to be easily uninstalled. For ASP.NET applications, an MSI file provides an opportunity to automatically create virtual directories, and an opportunity to automate any other settings tasks. The MSI deployment is the most effective for the application for the initial deployment of the new server.
In ASP.NET 2.0, you can use any of these methods, or to deploy directly from Visual Studio 2005 using the FTP or SharePoint communication options described in the next section.
Back to top
Update application
Once the ASP.NET application is deployed, you can use several different ways to update it by a few different ways to be assigned to the server.
Xcopy
ASP.NET is designed to reload applications when any application component changes. For example, if you copy the new DLL or ASPX page to the web server, the application will automatically load the changed code. You automatically update your application by simply copying the new file to the old file. Therefore, Xcopy provides you with a way to perform a plurality of web servers at a time without having to turn off the entire network field. You only need to perform a cross-copy operation for each server.
MSI
If you choose to update with an MSI file, you will have to create a new installation package and redeploy it. Since MSI uses the Microsoft Installer Framework, you may have to temporarily turn off your application to uninstall the old version and reallo the new version. Fortunately, because the ASP.NET application runs in its own CLR application domain, you don't have to restart the server or restart the IIS process. The application is just restarted in the new application domain within the CLR process.
During deployment, using MSI bags to update your ASP.NET application has several advantages than using XCopy. MSI usually does the best for multiple server deployments, or throughout deployment, testing, accepting, and production of several levels of complex deployment models.
Support for FTP, Share Point and IIS
Visual Studio 2005 has built-in support for editing and updating remote Web projects. You can use File Transfer Protocol (FTP), Microsoft Share Point, or to update and maintain your application by direct communication with local accessible IIS instances. A variety of ways makes your deployment and maintenance applications simple.
Figure 2. FTP Maintenance dialog
For example, if you or use the open web site dialog, or use the New Web Site dialog box, you can connect to a web site and use FTP to transfer or update files.
Don't use FrontPage
ASP.NET 1.x applications are designed to be integrated with IIS via Microsoft FrontPage Server Extensions (FPSE). But FPSE adds additional management burden and security risks. Many host companies think that fpse is a "unnecessary service" and disabled it, so that ASP.NET developers use other ways to deploy and use their applications. In ASP.NET 2.0, FPSE is no longer necessary or necessary. Due to the deployment and update options described above, Visual Studio 2005 developers have more and better options to publish their code to the web server.
Back to top
IIS configuration
Currently, most ASP.NET 1.x applications are running on Microsoft IIS 5.0. ASP.NET 2.0 is designed to take advantage of IIS 6.0. IIS 6.0 is safe installation, because it is configured in a locked state, and what does not do in addition to the service static web page. This helps to eliminate some denial of service attacks, these attacks are targeted by you even don't know what is running. You must manually configure the software to perform more advanced features such as ASP and ASP.NET Site Services. When you add advanced features, IIS 6.0 will give you a warning for potential security risks and recommend the best way to configure server security. At the same time, IIS 6.0 has more stringent restrictions and timeout settings so that software exhibits fewer attacks on the outside world.
Transplant from IIS 5.0
When you migrate from IIS 5.0 to IIS 6.0, there are several issues that may occur (for example, the problem of the DSN and ODBC connections, ISAPI applications, and COM components), but the most common migration problem occurs because IIS 6.0 You can run in one of two distant different mode of operation (they are referred to as application isolation mode). The application isolation is separated by the process boundary to prevent the application from impact. The application is isolated into each of the two IIS application isolation modes.
•
IIS 5.0 isolation mode. IIS 5.0 Isolation mode should only be used when the application rely on the memory model and process of IIS 5.0. You may have configured the ASP.NET application to use the IIS 5.0 model. Use IIS 5.0 isolation mode if you want to continue to use IIS 5.0 (requires the Machine.Config file settings).
•
Auxiliary process isolation mode. Auxiliary process isolation mode Run all applications in an isolated environment. Unlike IIS's early versions, only few processor instructions are running when you switch from an application pool to another, so there is no performance counter. The auxiliary process isolation mode is compatible with most existing Web sites and applications, and is now the default setting. As long as it is possible, IIS 6.0 is run in an auxiliary process isolation mode to benefit from the enhanced performance and security in IIS 6.0.
IIS 6.0 architecture
Figure 3. Comparison of IIS architecture
About the new IIS 6.0 architecture, the first thing to note is that the HTTP listener and cache of the core layer is run to maximize performance. Other parts of the web application run in user-level.
Web Management Services (WAS) replaces iisadmin as a user mode component of the web server. WAS can monitor applications to discover delay processes, stop and restart applications, and provide services including processor relationships.
Each application runs in the context of the application pool. An application pool can contain one or more applications. Each application in a pool share a master process (W3WP.exe). You can group related applications using the application pool and optimize resource usage.
Back to top
Application reliability
The purpose of the IIS 6.0 architecture is to completely isolate each application with other applications and core web servers. IIS 6.0 allows you to implement several functions to improve applications reliability. Regular application recycling
In order to improve application reliability, IIS 6.0 implements a periodic process recycling. When a condition (for example, normal running time, request quantity, predetermined time, memory consumption) is satisfied, your application will automatically restart. Recycling applications ensures that your application is available and prevents malicious application takeover systems. It should be noted that when your application is reclaimed, you must create a code to keep the status.
Figure 4. Recycling Access Process Dialog
Pinging
A health check (pinging) is intended to detect any deadlock in the auxiliary process thread. Each auxiliary process (w3wp.exe) thread is ping. If the process does not respond within the specified time, this process will be canceled (default), or you can configure the process to perform a certain action.
Figure 5. Enable pinging dialog
Crash detection and fast failure protection
IIS 6.0 can be detected when an auxiliary process crashes. If there is no interruption in the service, IIS 6.0 will automatically launch a new process.
Figure 6. Adjusting the failover attribute
Back to top
Current dollar database in XML
IIS 6.0 The dollar database implements several key changes. The metabase is a memory resident database for storing large part of IIS configuration settings. IIS 6.0 will be changed from a proprietary binary format to an XML format so that you can edit and configure the metadata according to your specified. IIS 6.0 allows you to edit the metadata without stopping IIS services on your machine. This significantly reduces the computer time of the application.
IIS 6.0 implements metadata resource manager, making backup and recovery metadata easier - even backup or stored in different machines. This feature allows you to create a host, which can be cloned on another machine. As long as you make any changes to the metadata, the new metadata history feature automatically creates a backup.
Figure 7. Yuan Database Explorer
For more information on porting to IIS 6.0 and new features, see: Inside IIS and this Microsoft PowerPoint Demo: http://support.microsoft.com/servicedesks/webcasts/wc112002/wc112002.ppt.
Back to top
Manage web applications
Once you deploy the Web site on a production server, you still have to manage this app. In particular, if you deploy an ASP.NET 2.0 application that uses new personalized, members, and profile features, you will need to make sure that the provider is configured correctly and the user and the role are correctly defined.
Web Site Management Tool Overview
To simplify the process of managing users, ASP.NET 2.0 provides a built-in Web site configuration tool. The Web Site Management Tool is a simple Web site that can only be accessed by secure connection or directly on this unit. With this tool, administrators can manage applications by configuring services such as user management, personalized providers, security, and profiles. This tool also allows you to easily configure counters, debug, and track information for your application.
Figure 8. Web site management tool
Management provider
Web Site Management Tools allow you to manage the provider without writing any code. Just click on the Provider tab, you can choose configuration, delete, or add a new provider to store site information.
Figure 9. Provider Management Screen
In Beta 1, the ASP.NET 2.0 web application includes a Microsoft Access database to host all your application information (ASPNetAccessProvider). In the future, the default provider may be migrated to Microsoft SQL Server Express.
When you add a new provider, ASP.NET automatically generates a database in the C: // inetpub / application_name / data folder. The code in the list 1 is automatically added to the Machine.config file. List 1. Machine.config file
The database contains predefined tables to carry users, roles, profiles, and additional information for your site.
Figure 10. Sample table from the ASPNET database
ASP.NET 2.0 provides a provider model that allows you to use any type of database for your provider, but manage tools only support Microsoft Access and SQL Server databases.
Manage user
The security page for the Web site management tool allows you to add and edit users, roles, and access rules.
Figure 11. Security configuration options
This tool allows you to create roles and users. The user can be assigned to the role by simply selecting a check box for the available role.
Figure 12. User Management Screen
Manage other features
The Web site management tool also allows you to store profiles and application information. By storing a user's profile information, you can display custom information and layout for each user according to user preferences. You can store information as a .NET data type or a custom data type.
Figure 13. Profile Properties Settings screen
The application management screen allows you to configure Site statistics (for example, counters), applications SMTP options, application settings, and debugging options. The debug area also allows you to set the default or custom error page and message.
Back to top
Monitor .NET application
Since most of the Web sites rely on fast data transmission and have more and more users, monitoring the performance of the web application is necessary. .NET Framework 1.x contains many tools for monitoring applications. .NET Framework 2.0 extends existing features and contains several new features to help you monitor your application more effectively more accurately.
Back to top
Debugger visualization
When debugging using Microsoft Visual Studio .NET, if the load size is large or containing XML, it is sometimes difficult to view the load of variables, attributes, or objects in IDE. Visual Studio 2005 implements built-in visualization tools to help you easily view information stored in any variable. You can choose to view variables in text, HTML, or XML browser. This is easier when the data is HTML, XML or when the value is a long string, this is easier to see the value assigned to the variable.
Figure 14: Debugger visualization
Back to top
Unicode Conversion Format: 8 Log Record
IIS 6.0 supports Unicode logging. UTF-8 represents the Unicode (or UCS) conversion format, 8-bit encoding form. UTF-8 is a transport format for Unicode that applies to many network protocols and UNIX file systems. Using UTF-8 allows you to import and export log results into machines running different languages, operating systems, or protocols and ensure that results are still readable.
Back to top
Performance counter
Performance counters are multi-group data published by applications, services, or operating system processes to help diagnose and analyze throughput and bottlenecks. Microsoft Windows 2000, Windows XP, and Microsoft Windows Server 2003 supports counters. Performance counters are the first line of monitoring. The counter provides you with information to help you identify low-performance areas, which can also be used as a trigger to point out if you need to do more analysis. Figure 15. Visual Studio control properties window
Visual Studio 2005 has an option in the Properties window that you can add a simple performance counter to your control without writing any code. You can track the page URL by simply setting the property to TRUE by simply setting the property to True.
Back to top
Event tracking
Event Tracking Allows you to collect important information when you are in an event (for example, when you log in to your application). Event tracking is highly scalable and only requires little system overhead (5% or less CPU overhead). The following chart shows the event tracking model:
Figure 16: Event tracking model
The event is recorded by an event tracking session. This event tracking model is the same as the event tracking model provided in ASP.NET 1.x, but several new events (used for analysis, compilation, and rendering) are available. The system can support 32 simultaneous event tracking sessions. On Windows 2000, two of these sessions are reserved for special purposes. On Windows XP, three of these sessions are retained. The remaining session can be used in general. Each event tracking session maintains a set of buffers (called buffer pools), where tracking sessions temporarily store event data.
Controller
Event Tracking Controller Starts and Stop Event Tracking Sessions, Manages Buffer Pools, and obtains execution statistics for sessions. Session statistics include the number of buffers used, the number of buffers passing, lost events, and the number of buffers, and the size and location of the log file (if it uses it).
Use the Tracerpt.exe utility to control events. Tracerpt.exe can generate a report and dump all tracking information to .csv format.
Listing 2. Control events using Tracerpt utility
Tracerpt mylog_000001.etl
Provider
Event Tracking Provider is responsible for the passage of the event. Event Tracking Provider Registration Event Classification and gives each event class a unique GUID, which allows classes to talk to Windows service with the event listener. Once the event tracker is registered, you can enable or disable it via the event tracking controller. In general, if a provider has been enabled, it will generate an event, but it will not generate an event when it is disabled. This allows you to add event tracking to applications that are not run at any time.
user
Event Tracking users can select one or more event tracking sessions as the source of events. Users can track sessions from multiple event tracks, and your system will return events in chronological order. Users can receive events stored in a log file or from a session from real-time delivery events. You can specify the startup and stop time to ensure that events that occur within the specified time range are passed.
You can perform an event-based operation using the installed standard user class in the operating system. Standard users are a simple definition of the registered class for the user class. When it receives an event notification, each standard user performs a specified operation.
