Professional ASP.NET 1.0 Special Edition- P23 pdf

</system.web> </configuration> The <sessionState> configuration setting supports six attributes (we will show their use shortly):  mode - The mode setting supports four options; Off, InProc, SQLServer, and StateServer. The InProc option, the default, enables in-process state management. In-process state management is identical to the behavior of ASP Session. There are also two options for out-of-process state management: a Windows NT Service ( StateServer) and SQL Server (SQLServer).  stateConnectionString - Identifies the TCP/IP address and port used to communicate with the Windows NT Service providing state management facilities. We must configure the stateConnectionString when mode is set to StateServer.  stateNetworkTimeout - Controls the timeout, in seconds, allowed when attempting to store state in an out-of-process session store.  sqlConnectionString - Identifies the database connection string that names the database used for mode="SQLServer". This includes both the TCP/IP address identified by data source as well as a username and password to connect to the SQL Server database.  cookieless - Enables support for Session key management without requiring HTTP cookies.  timeout - This option controls the life of a user's Session. timeout is a sliding value, and on each request, the timeout period is reset to the current time plus the timeout value. Next, let's implement some of the common scenarios we'll encounter when building applications using Session state. Supporting Web Farms By default, ASP.NET ships with Session state configured to store Session data in the same process as ASP.NET. This is identical to how ASP Session data is stored. The session web farm feature allows several front-end web servers to share a common storage point for Session data, rather than each web server maintaining its own copy. This creates a scenario in which the client making the request can be serviced from any server within the server farm. This additionally allows an individual server's process to recycle and access to Session data to be maintained. We have two options for out-of-process Session state; a Windows NT Service, which stores the data (in memory) in a separate process from ASP.NET (either on the same server or on a different server), and a SQL Server option, which stores the data in SQL Server. Let's look at how we configure both of these options. Out-of-Process - Windows Service To support the out-of-process Windows Service option (mode="StateServer") we need first to decide which server is going to run the Windows Service used for Session state storage. ASP.NET ships with a Windows Service named aspnet_state that needs to be running in order for Session to function in mode="StateServer". The service can be started by opening a command prompt and entering the following in bold: > net start aspnet_state The ASP.NET State Service service is starting. The ASP.NET State Service service was started successfully. Alternatively, we can configure the service using the Services and Applications Microsoft Management Console MMC snap-in (available from Start|Settings|ControlPanel|AdministrativeTools|ComputerManagement). If we view the Services item in this tool, we are presented with a list of the available services on the server: Right-clicking on the ASP.NET State Service item opens up a menu that allows us to configure how this service is to be run. We can select the start-up options (whether or not Windows should automatically start this service for us) as well as using the toolbar Start and Stop buttons to enable or disable this service ourselves. Once the service has been started, we then need to configure ASP.NET to use this particular service. This is done through our configuration file. We need to tell ASP.NET which server and port to use for communication with our ASP.NET State service, as well as the fact that we want to use the Windows Service state option. Here is our web.config, with the necessary settings highlighted: <configuration> <system.web> <sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424" stateNetworkTimeout="10" sqlConnectionString="data source=127.0.0.1; user id=sa;password=" cookieless="false" timeout="20" /> </system.web> </configuration> In the above example, ASP.NET Session is directed to use the Windows Service for state management on the local server (address 127.0.0.1 is the TCP/IP loop-back address). The default port that aspnet_state uses to communicate is port 42424; we can configure this to any other port we wish, but this configuration must be done through the system registry. To configure to the port 100, run RegEdit.exe, expand HKEY_LOCAL_MACHINE|SYSTEM|CurrentControlSet|Services|aspnet_state| Parameters. Within Parameters we will find a Port setting, which allows us to configure the TCP/IP port on which the aspnet_state service uses to communicate: If we want to enable state for all of our servers in a server farm to point back to a single state server, we need to change the IP address to reflect the IP address of the server running the Windows NT Service and we also need each of the server's machine keys to be identical. This last point is very, very important. Each server, by default, is set to auto-generate its own machine key. This machine key is used to encrypt data or to create unique serverspecific values for data (known as hashing). The ID used for Session state is created using the machine key, and thus, for the key to be understood by all the servers in the farm the servers need the same machine key. The machine key has other applications besides sessionState and we will cover it in more detail later in the chapter. In addition to supporting an out-of-process Windows Service, ASP.NET additionally supports an out-of-process option that saves Session data to SQL Server. Out-of-Process - SQL Server Configuring ASP.NET to support SQL Server for Session state is just as simple as configuring the Windows Service. The only difference is that we will use SQL Server. To configure SQL Server we need to run a T-SQL script that ships with ASP.NET, InstallSqlState.sql. A T-SQL script to uninstall ASP.NET SQL Server support is also included, called UninstallSqlState.sql. It should be noted that ASP.NET ships with a lightweight version of SQL Server 2000 that has several limitations (limited connections, throttled transactions, and so on) but is for all practical purposes, a normal working version of SQL Server 2000. We can use this developer version of SQL Server 2000 for development purposes, but if we were to deploy and use SQL Server for state management in a production server farm we would want to use SQL Server 2000 Standard or Enterprise versions for optimal performance. To run the InstallSqlState.sql script, we will use a tool that ships with SQL Server (and MSDE); OSQL.exe. OSQL allows us to apply a T-SQL script to a SQL Server. Our InstallSqlState.sql T-SQL script creates several stored procedures and creates several temporary databases for ASP.NET Session to use. The script only needs to be run once on any given SQL Server, and we will need sa (administrator) level access to run the script. To run the script, open a command prompt and navigate to the \WINNT\Microsoft.NET\Framework\[version]\ directory and type: > OSQL -S localhost -U sa -P <InstallSqlState.sql 1> 2> 3> 1> 2> 3> 4> 5> 6> 1> 2> 3> 4> 5> 6> 1> 2> 3> 4> 5> 1> 2> 3> 4> 5> 6> 7> 8> 1> 2> 3> 4> 5> 6> 7> 8> 1> 2> 3> 4> 5> 6> 7> 8> 1> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21> 22> 23> 1> 2> 3> 4> The CREATE DATABASE process is allocating 0.63 MB on disk 'ASPState'. The CREATE DATABASE process is allocating 0.49 MB on disk 'ASPState_log'. 1> 2> 3> 1> 2> 3> 1> 2> 1> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 1> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21> 22> 23> 24> 25> 26> 27> 28> 29> 30> 31> 1> 2> 3> 4> 5> 6> 7> 1> 2> 3> (1 row affected) Type added. 1> 2> 3> (1 row affected) Type added. 1> 2> 3> (1 row affected) Type added. 1> 2> 3> (1 row affected) Type added. 1> 2> 3> (1 row affected) Type added. 1> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21> 22> 1> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21> 22> 23> 24> 25> 26> 27> 28> 29> 30> 31> 32> 33> 34> 35> 36> 37> 1> 2> 3> 4> 5> 6> 7> 8> 9> 10> 11> 12> 13> 14> 15> 16> 17> 18> 19> 20> 21> 22> 23> 24> 25> 26> 27> 28> 29> 30> 31> 32> 33> 34> 35> 36> 37> 38> 39> 40> 41> 42> . . . . . . . . . . . . . . . . . . . . . Next, we need to change our configuration settings to use SQL Server (highlighted): <configuration> <system.web> <sessionState mode="SQLServer" stateConnectionString="tcpip=127.0.0.1:42424" stateNetworkTimeout="10" sqlConnectionString="data source=127.0.0.1; user id=session;password=&363test" cookieless="false" timeout="20" /> </system.web> </configuration> First, we set mode="SQLServer" and then we configure the sqlConnectionString to point to the server that has the T-SQL script installed. Session data stored in SQL is inaccessible to other applications. It is serialized as a protected type and should not be read or modified by applications other than ASP.NET. ASP.NET accesses the data stored in SQL via stored procedures. By default, session data is stored in the TempDB database. The stored procedures may be modified, for example, if we wished to store to tables other than TempDB. However, this is an option best saved for DBAs. From the developer's point of view, writing code that uses Session in any of the above modes is completely transparent. However, we should briefly discuss choosing a mode as the mode selection can impact on the performance of the application. Choosing a Mode There are three modes from which we can choose when building an application:  In-process (default) - In-process will perform best because the Session data is kept within the ASP.NET process and local memory access will always be faster than having to go out-of-process. Additional reasons include web applications hosted on a single server, applications in which the user is guaranteed to be redirected to the correct server, or when Session data is not critical (in the sense that it can be easily re-created).  Windows Service - This mode is best used when performance is important and there are multiple web servers servicing requests. With this out-of-process mode, you get the performance of reading from memory and the reliability of a separate process that manages the state for all servers.  SQL Server - This mode is best used when the reliability of the data is fundamental to the stability of the application, as the data is stored in SQL Server. The performance isn't as fast as the Windows Service, but the tradeoff is the higher level of reliability. Now that we have examined the supported options for web farms, let's turn our attention to another one of the great new features of ASP.NET Session: support for clients that don't accept HTTP cookies. Cookieless Session Since HTTP is a stateless environment, in order to maintain state across requests through Session, both the client and the server need to maintain a key. This key is used to identify the client's Session across requests. The server can then use the key to access the data stored for that user. By default, the server gives the client a key using an HTTP cookie. On subsequent requests to that server, the client will present the HTTP cookie and the server then has access to the session key. However, some clients choose not to accept HTTP cookies for a variety of reasons, a common one being the perceived privacy issue. When this happens the site has to either 'adapt' and not support cookies (and Session), or build the application to not require use of Session. A third option, first provided with IIS 4, is an ISAPI filter that can extract the session ID out of the cookie and pass it as part of the URL. This concept is supported by ASP.NET as a first class feature. This feature is known as cookieless Session state, and it works with any of the supported mode options. Individual applications can be configured to support either cookie or cookieless, but not both. We can enable cookieless Session support by simply setting a flag in our configuration system (highlighted): <configuration> <system.web> <sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424" stateNetworkTimeout="10" sqlConnectionString="data source=127.0.0.1; user id=sa;password=" cookieless="true" timeout="20" /> </system.web> </configuration> Similar to all configuration changes in ASP.NET, the settings are applied immediately. After changing cookieless from false (default) to true, the session ID is embedded in the URL of the page: As you can see from this, the session ID reqe3wvsxfoabvilmkmvq2p is embedded within the URL. Below is the source in Visual Basic .NET for this. You will notice that no special changes have been made to the sourcecode to support embedding the Session ID in the URL: <Script runat=server> Public Sub Session_Add(sender As Object, e As EventArgs) Session("cart") = text1.Value span1.InnerHtml = "Session data updated! <P>" + _ "Your session contains: <font color=red>" + _ Session("cart") + "</font>" End Sub Public Sub CheckSession(sender As Object, e As EventArgs) If (Session("cart") Is Nothing) Then span1.InnerHtml = "NOTHING, SESSION DATA LOST!" Else span1.InnerHtml = "Your session contains:" + _ "<font color=red>" + Session("cart") + "</font>" End If End Sub </Script> <form runat=server> <input id=text1 type=text runat=server> <input type=submit runat=server OnServerClick="Session_Add" Value="Add to Session State"> <input type=submit runat=server OnServerClick="CheckSession" Value="View Session State"> </form> <a href="SessionState_cs.aspx">C# Example</A> <hr size=1> <font size=6><span id=span1 runat=server/></font> Additionally, for relative URLs (as viewed by the browser) within the page, such as: <a href="SessionState_cs.aspx">C# Example</a> ASP.NET will automatically add the session ID into the URL. Below is the link that the client receives: [...]... not use the rich, developeroriented ASP.NET error page If a custom error page is not provided, ASP.NET will show the error page describing how to enable remote viewing of errors Off - ASP.NET will always use ASP.NET' s rich error page, with stack traces and compilation issues, when an error occurs Always Showing ASP.NET Error Pages If we want to always show the rich ASP.NET error page, such as when a... such as 0x800A01A8 ASP.NET makes some dramatic improvements on the level of detail available when errors occur, however, we don't always want that type of rich data displayed to end users With ASP.NET' s custom errors configuration option, we can control how ASP.NET displays application error messages Custom Errors When a run-time or design-time error occurs within our application, ASP.NET will display... application is configured to send SOAP replies ASP.NET provides a flexible framework for building web services As part of that framework, we have the ability to configure aspects of ASP.NET web services Although there are other configuration options for web services, the only one we will address is changing the ASP.NET page used to create the web service Help page: The ASP.NET page used to create this view... settings that ASP.NET uses to compile ASP.NET resources, such as ASP.NET pages A common setting that we can change if we don't want Visual Basic.NET to be our default language is the defaultLanguage option This is where we can also add additional CLR compilers, such as COBOL or Perl It is within the settings that we also name the assemblies (compiled reusable code libraries) that ASP.NET will... can then view! Let's look at an example to show how this is done ASP.NET takes a source file, such as the ASP.NET page below, compiles it, and saves the resulting NET dll file to disk in a directory under \WINNT\Microsoft.NET\Framework\[version]\Temporary ASP.NET Files\ Directories found within this directory are unique directories that ASP.NET creates automatically Let's look at what happens when we... lblHello.Text = "Hello!", along with the rest of the code that ASP.NET automatically generated to build our ASP.NET page If you ever want to know what an ASP.NET page is doing behind the scenes, this is a great resource Changing the Default Language The defaultLanguage attribute of allows us to configure the default language that ASP.NET resources use In code samples within this book, we... to ASP.NET requests, so our earlier example of SomeRandomFile.aspx will now be redirected to FileNotFound.htm Configuring IIS and ASP.NET to Support the Same Error Pages It is possible to configure ASP.NET. .. whether or not an ASP.NET error message is displayed By default, the mode value is set to RemoteOnly Supported values include: RemoteOnly - ASP.NET error page is shown only to users accessing the server on the same machine (that is the localhost or 127.0.0.1) Non-localhost requests will first check the settings, then use the defaultRedirect, or finally show an IIS error On - ASP.NET will use... customize DefaultWSDLHelpGenerator.aspx, we can instruct ASP.NET to use our custom file: We could use the above web.config file in our application and instruct ASP.NET to use a custom template page used to describe an ASP.NET web service Internationalization and Encoding... output status details, which are all items that were never intended to be shown We also couldn't trace a deployed application, since the users would see the Response.Write() trace results! ASP.NET Tracing Using ASP.NET' s new tracing functionality, we replace the Response.Write() statements with Trace.Write() statements: Public Function Add(a As Integer, b As Integer) As Integer . 9> 10 > 11 > 12 > 13 > 14 > 15 > 16 > 17 > 18 > 19 > 20& gt; 21& gt; 22> 23> 1& gt; 2> 3> 4> The CREATE DATABASE process is allocating 0. 63 MB on disk 'ASPState' 7> 8> 9> 10 > 11 > 12 > 13 > 14 > 15 > 16 > 17 > 18 > 19 > 20& gt; 21& gt; 22> 23> 24> 25> 26> 27> 28> 29> 30& gt; 31& gt; 1& gt; 2> 3>. 1& gt; 2> 3> (1 row affected) Type added. 1& gt; 2> 3> 4> 5> 6> 7> 8> 9> 10 > 11 > 12 > 13 > 14 > 15 > 16 > 17 > 18 > 19 > 20& gt; 21& gt;