Throughout this chapter, we have alluded to the existence of a conceptual application containing Web pages and configuration settings. This is an important concept to grasp, especially when configuring your Web site for multiple concurrent users.
few notes’on terminology and application lifetime are necessary here. An application is defined as all files in your project, and is configured by the Web config.file.An Application object is created when an application is started for the first time, which will be when the first HTTP request arrives. Also at this time, the Application_Start event is triggered and a pool of HttpApplication instances is created. Each incoming request receives one of these instances, which performs request processing. Note that this means HttpApplicationobjects do not need to cope with concurrent access, unlike the global Application object. When all HttpApplication instances finish their work, the Application_End event fires and the application terminates, destroying the Application object.
The event handlers for the events mentioned earlier (along with handlers for all other events discussed in this chapter) can be defined in a Global. asax file, which you can add to any Web site project. The generated file contains blanks for you to fill in; for example:
protected void Application_Start (Object. sender, EventArgs e)
When an individual user accesses the Web application, a session is started. Similar to the application, this involves the creation of a user-specific Session object, along with the triggering of a Session_Start event. Within a session, individual requests trigger Application_BeginRequest and Application_ EndRequest events. These can occur several times over the scope of a session as different resources within the application are accessed. Individual sessions can be terminated manually, or will time out if no further requests are received. Session termination triggers a Session_End event and the destruction of the session object.
Against the background of this process, you can do several things to streamline your application. If all instances of your application use a single, resource-heavy object, for example, then you might consider instantiating it at the application level. This can improve performance and reduce memory usage with multiple users because in most requests no such instantiation will be required. .
Another technique you can use is to store session-level information for use by individual users across requests. This might include user-specific information that is extracted from a data store when the user first connects (in the Session_Start () event handler), and is made available until the session is terminated (through a timeout or user request).
These techniques are beyond the scope of this book – and you might want to consult Professional ASP. NET 2.0 (Wiley Publishing, Inc. ISBN 0-7645-7610-0) for details – but it helps to have a broad understanding of the processes.
Finally, you need to look at Web.config files. A Web site will usually have one of these in its root directory (although it is not created for you by default), and may have additional ones in sub directories to configure directory-specific settings (such as security). The PCSWebApp3Web site developed in this chapter received an auto-generated Web.conf ig file when you added a stored database connection string, which you can see in the file:
If you ran the project in debug mode, then you will also see some additional settings in the web. config file.
You can edit Web. config.files manually, but you can also configure Web sites (and their underlying configuration files) using a tool that is accessible on the Web site menu in Visual Studio, under ASP.NET Configuration. The display for this tool is shown in Figure 37-15.
As you can see from the text, this tool lets you configure a number of settings, including security. You will see much more of this tool in the next chapter .