Virtual Directory

The <virtualDirectory> element is a child of the <application> element and controls the configuration settings for a specific virtual directory. A virtual directory is a directory name (also referred to as path) that you specify in Internet Information Services (IIS) 7 and map to a physical directory on a local or remote server. The virtual directory name becomes part of the application's URL, and users can request the URL from a browser to access content in the physical directory, such as a Web page or a list of additional directories and files. If you specify a different name than the physical directory for the virtual directory, it is more difficult for users to discover the actual physical file structure on your server because the URL does not map directly to the root of the site.

In IIS 7, each application must have a virtual directory, known as the root virtual directory, and maps the application to the physical directory that contains the application's content. However, an application can have more than one virtual directory. For example, you might use a virtual directory when you want your application to include images from another location in the file system, but you do not want to move the image files into the physical directory that is mapped to the application's root virtual directory.

http://www.iis.net/configreference/system.applicationhost/sites/site/application/virtualdirectory

Difference between Application Pool and Application Domain

This question normally arises when configuring web applications.

To summarize, an AppPool consists of one or more processes.  Each web application that you are running consists of (usually, IIRC) one application domain.  The issue is when you assign multiple web applications to the same AppPool, while they are separated by the application domain boundary they are still in the same process.  This can be less reliable/secure than using a separate AppPool for each web application.  On the other hand, it can improve performance by reducing the overhead of multiple processes.

Application Pool

[quote]

An Internet Information Services (IIS) application pool is a grouping of URLs that is routed to one or more worker processes. Because application pools define a set of Web applications that share one or more worker processes, they provide a convenient way to administer a set of Web sites and applications and their corresponding worker processes. Process boundaries separate each worker process; therefore, a Web site or application in one application pool will not be affected by application problems in other application pools. Application pools significantly increase both the reliability and manageability of a Web infrastructure.

[/quote]

http://msdn.microsoft.com/en-us/library/dd470362.aspx

Application Domain

[quote]

A boundary that the common language runtime establishes around objects created within the same application scope (that is, anywhere along the sequence of object activations beginning with the application entry point). Application domains help isolate objects created in one application from those created in other applications so that run-time behavior is predictable. Multiple application domains can exist in a single process.

[/quote]

Which w3wp.exe process belongs to which App Pool

When you are debugging a ASP.NET web application which is hosted on IIS, you need to attach the particular worker process in Visual Studio to start debugging. The process to attach a process J is go to Tools > Attach Process or use shortcut key Ctrl+Alt +P. The process window will show the worker process (w3wp.exe) which is currently running on IIS. You need to select the process and click on attach button to start the debugging. Problem starts when you have multiple worker process running on IIS. If you have multiple sites hosted on IIS and each site having their own application pool then you will see the list of all worker process in the Process Attach window.

Whenever we create a new Application Pool, the ID of the Application Pool is being generated and it’s registered with the HTTP.SYS (Kernel Level of IIS). Thus, whenever HTTP.SYS  receives any request from any web application, it checks for the Application Pool and based on the application pool ID, it send the request to appropriate worker process

I will straight way show you how to do the same on command prompt for IIS 6 & 7:

 IIS 6:

1.       Go to command prompt (run->cmd)

2.       Go to system32, the prompt should be like -

Write C:\>cd WINDOWS\system32 and you will reach C:\WINDOWS\system32>

Since the cscript.exe  resides here.

3.       Next command is – cscript iisapp.vbs

IIS 7:

From IIS 7.0 you need you to run IIS Command Tool ( appcmd ) .
1.  Start > Run > Cmd
2. Go To Windows > System32 > Inetsrv
3. Run appcmd list wp

This will show you list worker process that is running on IIS 7.0 in the similar format of IIS 6.0

And you get all the w3wp.exe with process id with AppPool id.

C:\WINDOWS\system32>cscript iisapp.vbs

Microsoft (R) Windows Script Host Version 5.6

Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

W3WP.exe PID: 8104   AppPoolId: SharePoint - 7011

W3WP.exe PID: 8080   AppPoolId: SharePoint Central Administration v3

W3WP.exe PID: 7600   AppPoolId: SharePoint - 7010

W3WP.exe PID: 148   AppPoolId: MyWebApp

Debug your ASP.NET Application while Hosted on IIS

Overview

Generally we debug our ASP.NET web application from Visual Studio. Visual Studio has its own ASP.NET engine, which is capable enough to run and debug your web sites inside Visual Studio. However, if your site is hosted on IIS and you want to debug that site directly, how would you debug it? When we host sites on IIS, the Worker Process (w3wp.exe) is used to run the web application. We need to attach to this particular process from Visual Studio to debug the web application. This article describes the overall idea of debugging an application using this method. It also describes theWorker Process, Application Pool and selecting a particular process if there are multiple Worker Processes running on IIS, using iisapp.vbs. I hope you will enjoy this article and provide your valuable suggestions and feedback.

ASP.NET Debugging vs. IIS Debugging

Visual Studio has its own integrated debugging engine, which debugs our code when we run the application in Visual Studio. If we are developing a site and need to debug the code, we just set breakpoints and do the debugging (Note: In this article I do not describe how to set the debug mode).

When we run the application, execution breaks when certain a breakpoint is reached. It is very simple, because when an ASP.NET application is running in Visual Studio, it is under the control of the ASP.NET Engine which is integrated with Visual Studio. If you want to check which process is running for debugging, run the web application from Visual Studio: you will get a popup notification as shown below.

Fig. 1: Taskbar popup when debugging is started from Visual Studio

This indicates a process is starting to run the ASP.NET application. Double-click on the icon and a popup window will appear to show the details.

Fig. 2: Development Server process details

Behind the running process is WebDev.WebServer.exe. When We press F5 to run the application, this process starts to execute the it. If you want run the application from command prompt, you have to perform the following steps.

Steps to run a web application from the command prompt:

1. Open The Visual Studio command prompt
2. Run WebDev.WebServer

The following screen will come up. Check the Example section there.

Fig. 3: WebDev.WebServer usage notification

Now back to IIS debugging. IIS comes into the picture when we deploy or host the site. After deploying the site on IIS, if we want to debug the site there, we can't do it directly as in Visual Studio. IIS has its own Worker Process which takes care of all execution and maintenance of deployed web applications. I will describe the details of the Worker Process in a later section. So, if we have running process in IIS and we need to debug the application, first of all we have to attach to the correct process from Visual Studio. Before describing that, let's just have a look at the Worker Process and Application Pool.

What is the Worker Process?

The Worker Process (w3wp.exe) runs ASP.NET applications within IIS. All ASP.NET functionality runs under the scope of the Worker Process. When a request comes to the server from a client, the Worker Process is responsible for generating the request and response. Its also maintains the InProc session data. If we recycle the Worker Process, we will lose its state. For more information, read this article: A Low-Level Look at the ASP.NET Architecture

Application Pool

This is one of the most important things that you should create for your own application in a production environment. Application Pools are used to separate sets of IIS Worker Processes that share the same configuration. Application Pools enable us to isolate our web application for better security, reliability, and availability. The Worker Process serves as the process boundary that separates each Application Pool, so that when one Worker Process or application has an issue or recycles, other applications or Worker Processes are not affected.

Fig. 4: Relationship between Application Pool and worker process in IIS

Default Application Pool

The name of the default application of IIS 6.0 is DefaultAppPool. After hosting the site on IIS, if we check the properties of the virtual directory, we can to view that information as follows.

1. Start Menu → Run command → inetmgr
2. Expand DefaultWebSites or Other Web Sites, where you have created the virtual directory
3. Right Click on the virtual directory
4. Click on Properties

The following virtual directory properties screen will come up, showing the Application Pool name which is assigned to the selected site.

Fig. 5: Virtual directory properties showing Application Pool name

If you want to check the list of all Application Pools in IIS, you have to expand the Application Pool node on IIS Server.

Fig. 6: List of Application Pools

Now, each and every Application Pool should have the minimum of one Worker Process which takes care of the operation of the site which is associated with the Application Pool. Right-click on the Application Pool → go to thePerformance tab, check near the bottom of the tab, there is a web garden section, and by default, the number of Worker Processes is 1. An Application Pool containing more than one Worker Process called a Web Garden.

Fig. 7: Application Pool properties showing Web garden

Creating and Assigning an Application Pool

• Open the IIS Console, right-click on the Application Pools folder, select New
  
  Fig. 8-1
• Give the Application Pool ID and click OK.
  
  Fig. 8-2
• Now, right-click on the virtual directory and assign the newly created Application Pool to that virtual directory.
  
  Fig. 8-3

Now, this web site will run independently, within StateServerAppPool, so any problem related to other applications will not affect this application. This is the main advantage of creating a separate Application Pool.

How to start?

What I have said up to now give you a good idea of Worker Processes and Application Pools. You should have a clear understanding on these before going on to the next part. Now I will show you how to debug a site which is hosted on an IIS Server.

For the demonstration, I have created a web site called SampleWebSite and hosted it on to my local IIS. Below is default page output.

Fig. 9: Sample web site

Which process to attach to?

Now, as I have already explained, the process name is w3wp.exe, so we can check it from our Task Manager whether or not the Worker Process is running.

Fig. 10: Task Manager showing the running IIS process

Now we are going to attach to the process. In Visual Studio, go to Debug → Attach to Process

Fig. 11: Opening the Attach to Process window

After clicking Attach to Process, the following screen will come up

Fig. 12: Attach to Process window, showing a single Worker Process running

Now we are able to see that the Worker Process is running, and we need to attach that process. Select the process and click on the Attach button. After that, look at the two images below:

Fig. 13-1: Process attached successfully

Fig. 13-2: Process not attached

Did you notice the breakpoint symbol? If the Worker Process attached successfully, within the code, the breakpoint symbol should be a solid circle. Otherwise it will have a warning icon as shown. For a single Worker Process, this scenario is not common. However, when we have multiple Worker Processes running on IIS, then we can have some confusion. I will discuss the same in a later section.

Now if we click the Debug button after successfully attaching to the process, execution will stop at the breakpoint.

Next, let's have a look at what to do if we have multiple Worker Processes running.

How to attach to one of many running Worker Processes

Now, when this scenario will come up? When we have multiple sites hosted on IIS, and those sites have their own Application Pool. Now, multiple Application Pools means multiple Worker Processes are running.

Here I have three Application Pools in my IIS. They are:

1. Default Application Pool
2. Generic Application Pool
3. State Server Application Pool

Now, my SampleWebSite is associated with the DefaultAppPool. Now, I want to attach the process to debug mySampleWebSite. Follow the same steps as before. Open the Process Attach window:

Fig. 14: List of multiple Worker Process

Just have a look, there are three Worker Processes currently running, and you have to attach one of them. But, you do not know which Worker Process is the default Application Pool's. What you do is, you select any one of them at random, let's say the one with process ID = 4308, and suppose it is not the Worker Process for the default Application Pool. So what will happen if you attach to a wrong process? Check the image below:

Fig. 15: Breakpoint when the process is not attached correctly

Getting a list of running Worker Processes

Now what is the solution for the previous case? Here is a quick tip:

• Start → Run command → cmd
• Change directory to \Windows\System32
• Run the command: cscript iisapp.vbs

and wait for the output. Wow! You get a list of running Worker Process, Process ID and Application Pool Name!

Fig. 16: List of running Worker Processes with PID and Application Pool name

Attaching to the correct process

From here you can easily identify the correct Application Pool name and its process ID. Now, return to Visual Studio → Attach Process. Now you know that the process ID for Default Application Pool is 1772, so Attach to that process.

Fig. 17: Attach the correct process for debugging

Now, enjoy debugging!

Fig. 18: Breakpoint is ready

Summary

Sometimes we need to debug our application which is hosted on IIS. For that, we need to attach the running Worker Process to the Visual Studio. If we have multiple Worker Processes running on the IIS server, we can identify the appropriate Worker Process by using the command cscript iisapp.vbs.

AutoEventWireup attribute in Microsoft ASP.NET Web Forms

Let us understand the use of AutoEventWireup property with an example. Create an asp.net web application project.

A webform in asp.net raises several events in it's life cycle. The following are few of those events.
1. Page Load
2. Page Load Complete
3. Page PreRender
4. Page PreRenderComplete  

Copy and paste the following code in WebForm1.aspx.cs
protected void Page_Load(object sender, EventArgs e)
{
    Response.Write("Page Load <br/>");
}

protected void Page_LoadComplete(object sender, EventArgs e)
{
    Response.Write("Page LoadComplete <br/>");
}

protected void Page_PreRender(object sender, EventArgs e)
{
    Response.Write("Page PreRender <br/>");
}

protected void Page_PreRenderComplete(object sender, EventArgs e)
{
    Response.Write("Page PreRenderComplete <br/>");
}

Now in WebForm1.aspx, set AutoEventWireup=true
Run the application, and notice that the above event handler methods are executed as expected. We did not explicitly associate event handler methods to the events, but still the event handler methods are hooked up to their respective events. This is because we have AutoEventWireup attribute set to true.

Now, set AutoEventWireup=false
Run the application, and notice that none of the above event handler methods are executed. This is because, when "AutoEventWireup" property is set to false, the event handler methods does not get automatically associated with their respective events. We have to explicitly associate them by overriding OnInit() method as shown below. Now, copy and paste the following code in webform1.aspx.cs
protected override void OnInit(EventArgs e)
{
    this.Load += new EventHandler(Page_Load);
    this.LoadComplete += new EventHandler(Page_LoadComplete);
    this.PreRender += new EventHandler(Page_PreRender);
    this.PreRenderComplete += new EventHandler(Page_PreRenderComplete);
}

Run the application, and notice that the above event handler methods are executed as expected. 

Now, set AutoEventWireup=true

Run the application, and notice that every event handler method is executed twice. This is because, 
1. Setting AutoEventWireup=true, registered the event handler method's once, and
2. Overriding OnInit() method, has registered the same event handler method again

Important points to remember:
1. When AutoEventWireup is set to true and if you want the event handlers to be wired up with their events automatically, the event handler names should follow the standarad naming convention - Page_EventName.
2. AutoEventWireup can be set in the page directive or in web.config file.
3. To set autoEventWireup in web.config, use pages element as shown below.
<configuration>
   <system.web>
      <pages autoEventWireup="true" />
   </system.web>
</configuration>
4. If autoEventWireup, is set at both webform and web.config level, webform setting will take precedence over web.config setting.

So, AutoEventWireup is a boolean property which, when set to true, the page event handler methods are automatically wired with their respective events. If this property is set to false, then the event handler methods need to be explicitly associated with their respective events.