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 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>
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 1433. 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.
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.
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.