Pro ASP.NET 2.0 In CSharp 2005 (2005) [eng]

658 C H A P T E R 1 8 ■ W E B S I T E D E P L OY M E N T

writer.Write(_FileContent); writer.Flush();

stream.Seek(0, SeekOrigin.Begin); return stream;

}

}

The class’s constructor gets the virtual path as well as the content of the file. In the Open method, the string with the actual content gets saved to a MemoryStream, and this stream is then returned. ASP.NET uses the stream for reading the contents as if they were read from the file system—thanks to the abstraction of bytes through Stream classes.

The next step is to complete the VirtualPathProvider class. It needs to read the actual data for the files from the database. If a file doesn’t exist in the database, the provider just forwards the request to its previous provider (which has been selected by the infrastructure while registering in the static AppInitialize method). Add a method for retrieving the contents from the database to the MyProvider class introduced previously:

private string GetFileFromDB(string virtualPath)

{

string contents;

string fileName = virtualPath.Substring( virtualPath.IndexOf('/', 1) + 1);

// Read the file from the database SqlConnection conn = new SqlConnection();

conn.ConnectionString = "data source=(local);Integrated " + "Security=SSPI;initial catalog=AspContent";

conn.Open();

try

{

SqlCommand cmd = new SqlCommand(

"SELECT FileContents FROM AspContent " + "WHERE FileName=@fn", conn);

cmd.Parameters.Add("@fn", fileName); contents = cmd.ExecuteScalar() as string; if (contents == null)

contents = string.Empty;

}

catch

{

contents = string.Empty;

}

finally

{

conn.Close();

}

return contents;

}

The GetFileFromDB function does nothing other than get the filename from the virtual path and then read the contents for the filename from the database. (Remember, the filename is the primary key in the database defined, as shown in Figure 18-27.) This method is then used by both, the FileExists as well as the GetFile method, as shown in the following code snippet:

660 C H A P T E R 1 8 ■ W E B S I T E D E P L OY M E N T

Health Monitoring in ASP.NET 2.0

Health monitoring is a process for verifying the application’s state while being operated in production environments. It is used for several reasons, such as catching errors, getting notified in case of errors, analyzing the performance of the application, getting information about the payload for the application, and much more. Monitoring usually is implemented through a mechanism called instrumentation, which is a technique used for adding events, performance counters, and tracing capabilities to an application.

Through these tracing capabilities, administrators, operational staff, and developers have the possibility of monitoring the application based on several aspects. However, instrumentation is something that has to be integrated into the application’s architecture in a way that makes monitoring useful and convenient.

ASP.NET 2.0 ships with an integrated health monitoring system that is completely consumable through a health monitoring API. Therefore, the instrumentation capabilities are integrated into the platform itself. You will now learn about the fundamentals of this instrumentation system.

Understanding the Basic Structure

The system is split up into two major parts: types of events that are implemented in a set of event classes and providers that are responsible for processing different types of events. You can see this when looking at the basic structure of the health monitoring configuration that is part of the web.config configuration file:

<healthMonitoring Enabled="true|false" heartBeatInterval="time interval"> <providers>... </providers>

<eventMappings>... </eventMappings> <profiles>... </profiles> <rules>... </rules>

</healthMonitoring>

Through the <providers> element you can configure a number of providers responsible for event processing. The events that can be processed are registered through the <eventMappings> element. The connection between providers and events is drawn through the <rules> element, which defines the provider responsible for processing an event and some additional parameters.

The <rules> section on its own may reference profiles that are defined in the <profiles> section. These profiles are some additional parameters that can be used for configuring the behavior of the event processing mechanism. Examples for such parameters are the number of times the event has to happen until it is raised by the monitoring system and the time that has to take place between two events.

Events and Providers

The reasons for splitting events and providers into two components are of course extensibility and flexibility. The event itself defines a situation that has become reality in the application, and the provider specifies how the event will be processed. ASP.NET ships with several event providers for catching the following types of events that are all defined in the System.Web.Management namespace:

•Heartbeats are events that are raised in a regular interval defined in the web.config configuration file. They provide you with information about the running process in regular intervals for monitoring memory consumption, CPU processor load, and much more. The class that implements this event is the WebHeartBeatEvent class.

662 C H A P T E R 1 8 ■ W E B S I T E D E P L OY M E N T

Table 18-5. Continued

Basically, any type of provider can process these events. Again, the system ships with a couple of providers, but only some of them are really configured in the machine-wide configuration, as shown in the following code snippet:

<healthMonitoring...> <providers>

<add name="EventLogProvider" type="System.Web.Management.EventLogWebEventProvider,

System.Web,Version=2.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

<add name="SqlWebEventProvider" ConnectionStringName="LocalSqlServer" maxEventDetailsLength="1073741823"

buffer="false" bufferMode="Notification" type="System.Web.Management.SqlWebEventProvider,

System.Web,Version=2.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

<add name="WmiWebEventProvider" type="System.Web.Management.WmiWebEventProvider,

System.Web,Version=2.0.0.0,Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

</providers>

</healthMonitoring>

Although only the three providers shown in the previous code snippet are configured by default, the framework ships with five providers. If you need another provider, just write a class inherited from the ProviderBase class of the namespace System.Configuration.Provider, and register the provider in the <providers> section of the <healthMonitoring> section in your own web.config in the same way as in the previous code snippet. The framework ships with the following providers:

EventLogWebEventProvider: EventLogWebEventProvider is responsible for adding different types of events to the Windows event log of the local system.

MailWebEventProvider: MailWebEventProvider is a provider for sending events via SMTP to a configured e-mail address. The e-mail address is added as a parameter to the provider entry in the same way as the ConnectionStringName parameter of the SqlWebEventProvider shown in the previous code snippet.

SqlWebEventProvider: SqlWebEventProvider offers the possibility for storing events into a SQL Server–based database. Of course, the database requires some standard tables for the provider in place. The SQL scripts for creating and dropping those tables are available in the InstallWebEventSqlProvider.sql as well as UninstallWebEventSqlProvider.sql files in the .NET Framework directory.

TraceWebEventProvider: TraceWebEventProvider enables you to catch and add events to the ASP.NET trace, which can be viewed through the trace.axd handler of the runtime.

WmiWebEventProvider: WmiWebEventProvider allows you to publish events through WMI. You can catch these events like you do any other type of WMI event through the System.Management API or the unmanaged WMI provider APIs available for Windows.

Now that you know events define situations that might happen in the application and providers define the delivery mechanism for those events (which means how these events are processed), you can configure a simple application for using the health monitoring infrastructure. You just need to take any of the samples created previously, or create a new website with an empty Default.aspx page, and add the following configuration to the web.config file:

<healthMonitoring enabled="true"> <providers>

<add name="EmailProvider" type="System.Web.Management.SimpleMailWebEventProvider" from="testhealth@vpcbase.local" to="testdest@vpc.local"

subjectPrefix="Testing Health" buffer="true" bufferMode="Notification"/>

</providers>

<rules>

<add provider="EmailProvider" name="All App Events"

eventName="Application Lifetime Events"/> </rules>

</healthMonitoring>

In the previous example, you have added the e-mail provider for sending an e-mail in case of every application lifetime event. The defined element in the <rules> section connects the previously configured e-mail provider to the actual events. For the rule definition, you should use the friendly name defined for the registered event in the <eventMappings> section.

■Tip If you want to test this scenario quickly, you can use the POP3 server that ships with Windows Server 2003. When you set up the POP3 server, you can either configure it to create mailboxes based on Windows accounts or use password-based authentication and therefore create a user name/password combination for every mailbox you configure. After you have installed the POP3 server, just create a mailbox, launch Microsoft Outlook, and configure the previously configured mailbox. (The SMTP and POP3 server are both localhost in that case.) Afterward, you just need to configure the SMTP server for the ASP.NET application through the web administration site that results in adding the necessary configuration entries to the web.config file of the application. When starting and shutting down the application together with the web server, you will receive the appropriate events for the application.

664 C H A P T E R 1 8 ■ W E B S I T E D E P L OY M E N T

Summary

In this chapter you learned how to configure your web application on the target environment. For this step, IIS—the web hosting software included with Windows—plays a key role; you saw the different aspects of installing and configuring IIS on Windows 2000/XP and Windows Server 2003 systems.

You also learned about the process architecture of IIS 5.x and IIS 6.0, and you learned about the differences between those two architectures. While IIS 5.x uses a single process model and ASP.NET executes in a separate worker process called aspnet_wp.exe for executing managed applications, IIS 6.0 favors the more secure and reliable worker process model where you can configure as many processes as you want for running your web applications. Every worker process is configured through so-called application pools. Based on these pools you can configure recycling settings, performance and health settings, and a custom identity for every process. By default each process runs under the restricted Network Service account, but if additional permissions are required, you can configure your own identity.

Then you learned about how Windows and IIS share web applications through virtual directories. You learned how to configure those virtual directories and how to put them into their designated application pool when using IIS 6.0. You also learned how to create and configure application pools.

In addition, you learned all the details about deploying ASP.NET applications to the target environment. Although deploying ASP.NET applications merely requires copying them onto the target web server and sharing the directory as a virtual directory through IIS, you need to keep a couple of things in mind, such as validating the ASP.NET configuration, selecting the appropriate ASP.NET runtime because more than one version of ASP.NET can be installed on the target machine, and viewing the details of the different compilation possibilities when it comes to ASP.NET deployment.

Finally, we discussed the fundamentals of the health monitoring subsystem included with ASP.NET. This system gives you a basic infrastructure to instrument and monitor ASP.NET web applications based on events and providers. Events are just states that can become true in a web application, and providers are components for processing those events.

Basically the topics you learned in this chapter are the most important topics for website deployment. In addition, you might want to refer to the command-line administration available since IIS 6.0. Together with some other scripts (such as database scripts imported through osql.exe), they provide a mechanism for deploying ASP.NET web applications with simple scripts automatically.

P A R T 4

■ ■ ■

Security