This chapter is from the book
This chapter is from the book
This chapter is from the book
ASP.NET Configuration
In our discussion of session state we have seen a number of cases where it is desirable to be able to configure ASP.NET. There are two types of configurations:
Server configuration specifies default settings that apply to all ASP.NET applications.
Application configuration specifies settings specific to a particular ASP.NET application.
Configuration Files
Configuration is specified in files with an XML format, which are easy to read and to modify.
SERVER CONFIGURATION FILE
The configuration file is machine.config. This file is located within a version-specific folder under \WINNT\Microsoft..NET\Framework. Because there are separate files for each version of .NET, it is perfectly possible to run different versions of ASP.NET side-by-side. Thus if you have working Web applications running under one version of .NET, you can continue to run them, while you develop new applications using a later version.
APPLICATION CONFIGURATION FILES
Optionally, you may provide a file web.config at the root of the virtual directory for a Web application. If the file is absent, the default configuration settings in machine.config will be used. If the file is present, any settings in web.config will override the default settings.
CONFIGURATION FILE FORMAT
Both machine.config and web.config files have the same XML-based format. There are sections that group related configuration items together, and individual items within the sections. As an easy way to get a feel both for the format of web.config and also for some of the important settings you may wish to adjust, just look at the web.config file that is created by Visual Studio when you create a new ASP.NET Web Application project.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<!-- DYNAMIC DEBUG COMPILATION
Set compilation debug="true" to insert debugging
symbols (.pdb information) into the compiled
page. Because this creates a larger file that
executes more slowly, you should set this value
to true only when debugging and to false at all
other times. For more information, refer to the
documentation about debugging ASP.NET files.
...
-->
<compilation
defaultLanguage="vb"
debug="true"
/>
<!-- CUSTOM ERROR MESSAGES
Set customErrors mode="On" or "RemoteOnly" to
enable custom error messages, "Off" to disable.
Add <error> tags for each of the errors you want
to handle.
-->
<customErrors
mode="Off"
/>
<!-- AUTHENTICATION
This section sets the authentication policies of
the application. Possible modes are "Windows",
"Forms", "Passport" and "None"
-->
<authentication mode= "Windows" />
...
</system.web>
</configuration>
Application Tracing
Earlier in the chapter we examined page-level tracing, which can be enabled with the Trace="true" attribute in the Page directive. Page-level tracing is useful during development but is rather intrusive, because the page trace is sent back to the browser along with the regular response. Application tracing, which is specified in web.config, writes the trace information to a log file, which can be viewed via a special URL.
As a demonstration of the use of web.config, let's add application tracing to our original Hello.aspx application. The folder HelloConfig contains Hello.aspx and web.config. We have added a trace statement in
<%@ Page Language="VB" %>
<HTML>
<HEAD>
<SCRIPT RUNAT="SERVER">
Sub cmdEcho_Click(Source As Object, e As EventArgs)
lblGreeting.Text="Hello, " & txtName.Text
Trace.Write("cmdEcho_Click called")
End Sub
</SCRIPT>
</HEAD>
<BODY>
<FORM RUNAT="SERVER">Your name:
<asp:textbox id=txtName Runat="server"></asp:textbox>
<p><asp:button id=cmdEcho onclick=cmdEcho_Click Text="Echo"
runat="server" tooltip="Click to echo your name">
</asp:button></p>
<asp:label id=lblGreeting runat="server"></asp:label>
<P></P>
</FORM>
</BODY>
</HTML>
We have provided a trace section in web.config to enable tracing.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<trace
enabled="true"
/>
</system.web>
</configuration>
You can run this application from Internet Explorer by simply providing the URL http://localhost/Chap14/HelloConfig/Hello.aspx.9 Enter a name and click the Echo button. The application should run normally, without any trace information included in the normal page returned to the browser.
Now enter the following URL: http://localhost/Chap14/HelloConfig/ trace.axd (specifying trace.axd in place of hello.aspx), and you will see top-level trace information, with a line for each trip to the server, as shown in Figure 14–33. If you click on the "View Details" link, you will see a detailed page trace, as we saw earlier in the chapter. The detailed trace corresponding to the POST will contain the trace output "cmdEcho_Click called" provided by our own code.
)
Figure 14-33 Viewing the application trace log through the browser.
Session Configuration
As another example of configuration, modify the web.config file for Step 2 of the case study to change the timeout value to be 1 minute.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
...
<!-- SESSION STATE SETTINGS
By default ASP.NET uses cookies to identify which
requests belong to a particular session. If
cookies are not available, a session can be
tracked by adding a session identifier to the
URL. To disable cookies, set sessionState
cookieless="true".
-->
<sessionState
mode="InProc"
stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString=
"data source=127.0.0.1;user id=sa;password="
cookieless="false"
timeout="1"
/>
...
</system.web>
</configuration>
Now run the application, log in, do some work, and return to the home page. You should be welcomed by your name without having to log in again. Now do some more work, wait more than a minute, and return to the home page. Now the session will have timed out, and you will be redirected to log in again.