Professional ASP.NET 3.5 in C# and Visual Basic Part 66 ppsx

Evjen c12.tex V2 - 01/28/2008 2:25pm Page 607
Chapter 12: Introduction to the Provider Model
This single class for the personalization system inherits from the
ProfileProvider
base class. This is
illustrated in Figure 12-11.
Figure 12-11
As with the other providers covered so far,
SqlProfileProvider
connects to a Microsoft SQL Server
Express Edition file by default. Although this is the default, you can change the connection to work
with either SQL Server 7.0, 2000, 2005, or 2008. For instance, if you are connecting to a SQL Server 2005
database, you define your connection in the
web.config
and then associate your
SqlProfileProvider
declaration to this connection string. This scenario is presented in Listing 12-12.
Listing 12-12: Connecting the SqlProfileProvider to SQL Server 2005
<configuration>
<connectionStrings>
<add name="LocalSql2005Server"
connectionString="Data Source=127.0.0.1;Integrated Security=SSPI" />
</connectionStrings>
<system.web>
<profile>
<providers>
<clear />
<add name="AspNetSql2005ProfileProvider"
connectionStringName="LocalSql2005Server" applicationName="/"
type="System.Web.Profile.SqlProfileProvider, System.Web,
Version=2.0.0.0, Culture=neutral,

PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
Continued
607
Evjen c12.tex V2 - 01/28/2008 2:25pm Page 608
Chapter 12: Introduction to the Provider Model
<properties>
<add name="FirstName" />
<add name="LastName" />
<add name="LastVisited" />
<add name="Age" />
<add name="Member" />
</properties>
</profile>
</system.web>
</configuration>
Remember that to store profile information in your SQL Server database, you have to configure this
database so the proper tables, stored procedures, and other items are created. This task was discussed
earlier in the chapter.
The SiteMap Provider
Similar to the personalization provider just discussed, ASP.NET 3.5 provides a single provider to work
with sitemaps. Sitemaps are what ASP.NET uses to provide you with a centralized way of maintaining
site navigation. By default, the definition of a Web application’s navigation is located in a structured
XML file. The sitemap provider lets you interact with this XML file, the
.sitemap
file, which you create
for your application. The provider available for sitemaps is
System.Web.XmlSiteMapProvider
,which
provides you with the capability to use the ASP.NET navigation system to connect to an XML-based file.

This single class for the sitemap system inherits from the
StaticSiteMapProvider
base class, which is a
partial implementation of the
SiteMapProvider
base class. This is illustrated in Figure 12-12.
This is the first provider introduced so far that does not connect to a SQL Server database by default.
Instead, this provider is designed to work with a static XML file. This XML file uses a particular schema
and is covered in considerable detail in Chapter 14.
The code required to configure
XmlSiteMapProvider
is presented in Listing 12-13.
Listing 12-13: Defining an XmlSiteMapProvider instance in the web.config
<configuration>
<system.web>
<siteMap defaultProvider="MyXmlSiteMapProvider" enabled="true">
<providers>
<add name="MyXmlSiteMapProvider"
description="SiteMap provider that reads in .sitemap files."
type="System.Web.XmlSiteMapProvider, System.Web, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
siteMapFile="AnotherWeb.sitemap" />
</providers>
</siteMap>
</system.web>
</configuration>
608
Evjen c12.tex V2 - 01/28/2008 2:25pm Page 609
Chapter 12: Introduction to the Provider Model
Figure 12-12

The
XmlSiteMapProvider
allows only a single root element in the strictly designed
web.sitemap
file. The default file name of the XML file it is looking for is
web.sitemap
, although you can change this
default setting (as you can see in Listing 12-13) by using the
siteMapFile
attribute within the provider
declaration in the
web.config
file.
SessionState Providers
As mentioned in the beginning of the chapter, an original concept of a provider model existed when the
idea of managing session state in different ways was first introduced with ASP.NET 1.x. The available
modes of storing session state for your users include
InProc
,
StateServer
,
SQLServer
,oreven
Custom
.
609
Evjen c12.tex V2 - 01/28/2008 2:25pm Page 610
Chapter 12: Introduction to the Provider Model
Each mode has definite pros and cons associated with it, and you should examine each option thoroughly
when deciding which session state mode to use.

You can find more information on these session state modes in Chapter 22.
This provider model is a bit different from the others discussed so far in this chapter. The
SessionState-
Module
class is a handler provided to load one of the available session state modes. Each of these modes
is defined here:
❑
System.Web.SessionState.InProcSessionStateStore
: Provides you with the capability to
store sessions in the same process as the ASP.NET worker process. This is by far the best-
performing method of session state management.
❑
System.Web.SessionState.OutOfProcSessionStateStore
: Provides you with the capability to
store sessions in a process separate from the ASP.NET worker process. This mode is a little more
secure, but a little worse in performance than the InProc mode.
❑
System.Web.SessionState.SqlSessionStateStore
: Provides you with the capability to store
sessions in SQL Server. This is by far the most secure method of storing sessions, but it is the
worst performing mode of the three available methods.
These three modes for session state management are illustrated in Figure 12-13.
Figure 12-13
Next, this chapter reviews each of the three modes that you can use out of the box in your ASP.NET 3.5
applications.
610
Evjen c12.tex V2 - 01/28/2008 2:25pm Page 611
Chapter 12: Introduction to the Provider Model
System.Web.SessionState.InProcSessionStateStore
The

InProcSessionStateStore
mode is the default mode for ASP.NET 1.x as well as for ASP.NET 2.0
and 3.5. In this mode, the sessions generated are held in the same process as that being used by the
ASP.NET worker process (
aspnet_wp.exe
or
w3wp.exe
). This mode is the best performing, but some
problems exist with this mode as well. Because the sessions are stored in the same process, whenever
the worker process is recycled, all the sessions are destroyed. Worker processes can be recycled for many
reasons (such as a change to the
web.config
file, the
Global.asax
file, or a setting in IIS that requires the
process to be recycled after a set time period).
An example of the configuration in the
web.config
file for working in the InProc mode is presented in
Listing 12-14.
Listing 12-14: Defining the InProc mode for session state management in the
web.config
<configuration>
<system.web>
<sessionState mode="InProc">
</sessionState>
</system.web>
</configuration>
As you can see, this mode is rather simple. The next method reviewed is the out-of-process mode — also
referred to as the StateServer mode.

System.Web.SessionState.OutOfProcSessionStateStore
In addition to the InProc mode, the StateServer mode is an out-of-process method of storing session
state. This method does not perform as well as one that stores the sessions in the same process as the
ASP.NET worker process. This makes sense because the method must jump process boundaries to work
with the sessions you are employing. Although the performance is poorer than in the InProc mode, the
OutOfProcSessionStateStore
method is more reliable than running the sessions using
InProcSession-
StateStore
. If your application’s worker process recycles, the sessions that this application is working
with are still maintained. This is a vital capability for those applications that are critically dependent
upon sessions.
An example of using
OutOfProcSessionStateStore
is detailed in Listing 12-15.
Listing 12-15: Running sessions out of process using OutOfProcSessionStateStore
<configuration>
<system.web>
<sessionState mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424">
</sessionState>
</system.web>
</configuration>
611
Evjen c12.tex V2 - 01/28/2008 2:25pm Page 612
Chapter 12: Introduction to the Provider Model
When using the StateServer mode, you also must define where the sessions are stored using the
stateConnectionString
attribute. In this case, the local server is used, meaning that the sessions are
stored on the same machine, but in an entirely separate process. You could have just as easily stored the

sessions on a different server by providing the appropriate IP address as a value for this attribute. In
addition to the IP address, note that port 42424 is used. This port is required when using the StateServer
mode for sessions. Changing the port for the StateServer is detailed in Chapter 22.
System.Web.SessionState.SqlSessionStateStore
The final provider for session state management available to you in ASP.NET is the
SqlSessionState-
Store
. This method is definitely the most resilient of the three available modes. With that said, however,
it is also the worst performing of the three modes. It is important that you set up your database appro-
priately if you use this method of session state storage. Again, Chapter 22 shows you how to set up your
database.
To configure your application to work with
SqlSessionStateStore
, you must configure the
web.config
as detailed in Listing 12-16.
Listing 12-16: Defining SqlSessionStateStore in the web.config file
<configuration>
<system.web>
<sessionState mode="SQLServer"
allowCustomSqlDatabase="true"
sqlConnectionString="Data Source=127.0.0.1;
database=MyCustomASPStateDatabase;Integrated Security=SSPI">
</sessionState>
</system.web>
</configuration>
Next, you review the providers available for the Web events architecture.
Web Event Providers
Among all the available systems provided in ASP.NET 3.5, more providers are available for the health
monitoring system than for any other system. The new health monitoring system enables ASP.NET

application administrators to evaluate the health of a running ASP.NET application and to capture events
(errors and other possible triggers) that can then be stored via one of the available providers. These events
are referred to as Web events. A large list of events can be monitored via the health monitoring system,
and this means that you can start recording items such as authentication failures/successes, all errors
generated, ASP.NET worker process information, request data, response data, and more. Recording
items means using one of the providers available to record to a data store of some kind.
Health monitoring in ASP.NET 3.5 is covered in Chapter 33.
612
Evjen c12.tex V2 - 01/28/2008 2:25pm Page 613
Chapter 12: Introduction to the Provider Model
By default, ASP.NET 3.5 offers seven possible providers for the health monitoring system. This is more
than for any of the other ASP.NET systems. These providers are defined in the following list:
❑
System.Web.Management.EventLogWebEventProvider
: Provides you with the capability to use
the ASP.NET health monitoring system to record security operation errors and all other errors
into the Windows event log.
❑
System.Web.Management.SimpleMailWebEventProvider
: Provides you with the capability to
use the ASP.NET health monitoring system to send error information in an e-mail.
❑
System.Web.Management.TemplatedMailWebEventProvider
: Similar to the
SimpleMailWeb-
EventProvider
,the
TemplatedMailWebEventProvider
class provides you with the capability
to send error information in a templated e-mail. Templates are defined using a standard

.aspx
page.
❑
System.Web.Management.SqlWebEventProvider
: Provides you with the capability to use the
ASP.NET health monitoring system to store error information in SQL Server. As with the other
SQL providers for the other systems in ASP.NET, the
SqlWebEventProvider
stores error infor-
mation in SQL Server Express Edition by default.
❑
System.Web.Management.TraceWebEventProvider
: Provides you with the capability to use the
ASP.NET health monitoring system to send error information to the ASP.NET page tracing sys-
tem.
❑
System.Web.Management.IisTraceWebEventProvider
: Provides you with the capability to use
the ASP.NET health monitoring system to send error information to the IIS tracing system.
❑
System.Web.Management.WmiWebEventProvider
: Provides you with the capability to connect
the new ASP.NET health monitoring system, the Windows Management Instrumentation (WMI)
event provider.
These seven providers for the ASP.NET health monitoring system inherit from either the
WebEvent-
Provider
base class, or the
BufferedWebEventProvider
(which, in turn, inherits from

WebEventProvid-
er
). This is illustrated in Figure 12-14.
What is the difference between the
WebEventProvider
class and the
BufferedWebEventProvider
?The
big difference is that the
WebEventProvider
writes events as they happen, whereas the
BufferedWeb-
EventProvider
holds Web events until a collection of them is made. The collection is then written to the
database or sent in an e-mail in a batch. If you use the
SqlWebEventProvider
class, you actually want this
batch processing to occur rather than having the provider make a connection to the database and write
to it for each Web event that occurs.
Next, this chapter looks at each of the seven available providers for the health monitoring system.
System.Web.Management.EventLogWebEventProvider
Traditionally, administrators and developers are used to reviewing system and application errors in the
built-in Windows event log. The items in the event log can be viewed via the Event Viewer. This
613
Evjen c12.tex V2 - 01/28/2008 2:25pm Page 614
Chapter 12: Introduction to the Provider Model
Figure 12-14
GUI-based tool for viewing events can be found by selecting Administration Tools in the Control Panel
and then selecting Event Viewer.
By default, the health monitoring system uses the Windows event log to record the items that are already

specified in the server’s configuration files or items you have specified in the
web.config
file of your
application. If you look in the
web.config.comments
file in the CONFIG folder of the Microsoft .NET
Framework install on your server, you see that the
EventLogWebEventProvider
is detailed in this loca-
tion. The code is presented in Listing 12-17.
Listing 12-17: The EventLogWebEventProvider declared in the web.config.comments
file
<configuration>
<system.web>
<healthMonitoring heartbeatInterval="0" enabled="true">
<bufferModes>
<! Removed for clarity >
</bufferModes>
<providers>
<clear />
<add name="EventLogProvider"
614
Evjen c12.tex V2 - 01/28/2008 2:25pm Page 615
Chapter 12: Introduction to the Provider Model
type="System.Web.Management.EventLogWebEventProvider,
System.Web,Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
<! Removed for clarity >
</providers>
<profiles>

<! Removed for clarity >
</profiles>
<rules>
<add name="All Errors Default" eventName="All Errors"
provider="EventLogProvider" profile="Default" minInstances="1"
maxLimit="Infinite" minInterval="00:01:00" custom="" />
<add name="Failure Audits Default" eventName="Failure Audits"
provider="EventLogProvider" profile="Default" minInstances="1"
maxLimit="Infinite" minInterval="00:01:00" custom="" />
</rules>
<eventMappings>
<! Removed for clarity >
</eventMappings>
</healthMonitoring>
</system.web>
</configuration>
As you can see from Listing 12-17, a lot of possible settings can be applied in the health monitoring
system. Depending on the rules and event mappings you have defined, these items are logged into the
event log of the server that is hosting the application. Looking closely at the
<
rules
> section of the
listing, you can see that specific error types are assigned to be monitored. In this section, two types of
errors are trapped in the health monitoring system —
All Errors Default
and
Failure Audits Default
.
When one of the errors defined in the
<

rules
> section is triggered and captured by the health monitoring
system, it is recorded. Where it is recorded depends upon the specified provider. The provider attribute
used in the
<
add
> element of the <
rules
> section determines this. In both cases in the example in Listing
12-17, you can see that the
EventLogProvider
is the assigned provider. This means that the Windows
error log is used for recording the errors of both types.
As you work through the rest of the providers, note that the health monitoring system behaves differently
when working with providers than the other systems that have been introduced in this chapter. Using
the new health monitoring system in ASP.NET 3.5, you are able to assign more than one provider at a
time. This means that you are able to specify in the
web.config
file that errors are logged not only into
the Windows event log, but also into any other data store using any other provider you designate. Even
for the same Web event type, y ou can assign the Web event to be recorded to the Windows event log and
SQL Server at the same time (for example).
System.Web.Management.SimpleMailWebEventProvider
Sometimes when errors occur in your applications, you as an administrator or a concerned developer
want e-mail notification of the problem. In addition to recording events to disk using something such
as the
EventLogWebEventProvider
, you can also have the error notification e-mailed to you using the
SimpleMailWebEventProvider
. As it states in the provider name, the e-mail is a simply constructed one.

Listing 12-18 shows you how you would go about adding e-mail notification in addition to writing the
errors to the Windows event log.
615
Evjen c12.tex V2 - 01/28/2008 2:25pm Page 616
Chapter 12: Introduction to the Provider Model
Listing 12-18: The SimpleMailWebEventProvider definition
<configuration>
<system.web>
<healthMonitoring heartbeatInterval="0" enabled="true">
<bufferModes>
<add name="Website Error Notification"
maxBufferSize="100"
maxFlushSize="20"
urgentFlushThreshold="1"
regularFlushInterval="Infinite"
urgentFlushInterval="00:01:00"
maxBufferThreads="1" />
</bufferModes>
<providers>
<clear />
<add name="EventLogProvider"
type="System.Web.Management.EventLogWebEventProvider,
System.Web,Version=2.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
<add name="SimpleMailProvider"
type="System.Web.Management.SimpleMailWebEventProvider,
System.Web, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a"
from=""
to=""

cc="
bcc=""
bodyHeader="Warning!"
bodyFooter="Please investigate ASAP."
subjectPrefix="Action required."
buffer="true"
bufferMode="Website Error Notification"
maxEventLength="4096"
maxMessagesPerNotification="1" />
</providers>
<profiles>
<! Removed for clarity >
</profiles>
<rules>
<add name="All Errors Default" eventName="All Errors"
provider="EventLogProvider" profile="Default" minInstances="1"
maxLimit="Infinite" minInterval="00:01:00" custom="" />
<add name="Failure Audits Default" eventName="Failure Audits"
provider="EventLogProvider" profile="Default" minInstances="1"
maxLimit="Infinite" minInterval="00:01:00" custom="" />
<add name="All Errors Simple Mail" eventName="All Errors"
provider="SimpleMailProvider" profile="Default" />
<add name="Failure Audits Default" eventName="Failure Audits"
provider="SimpleMailProvider" profile="Default" />
</rules>
<eventMappings>
616