: Does IIS 7.5 use a separate "AppDomain" for each subdomain? Within an IIS worker process, separate sites (i.e. domains) run in their own app domain. I have a site example.com which has a wildcard

@Looi9037786

No. I run several sites like this. The binding determines which app takes the requests, and each app can only have one app pool. An app pool can use multiple processes (a web garden) but that is completely unrelated to wildcard domain names (even a single domain gets split across multiple processes in this scenario).

An app domain (a security construct within .Net) isolates applications from each other. Each application only gets one app domain per process, regardless of how many domains bind to it. Even without wildcard DNS, if two completely separate domains are bound to the same application, such as abc.com and foo.xyz.net, they are both handled by the same app domain in the same app in the same process(es) in the same app pool.

Here's an overview of how an incoming request is handled by IIS (ignoring ISAPI filters, URL rewriting, etc.), gleaned from 15 years of research and experience dealing with two large multi-domain applications on IIS 5-8.5:


The IP address and port number of the incoming request (comes from the network interface) check to see if there is an SSL(TLS) certificate bound to the port. If so, SSL(TLS) negotiation begins. This happens before IIS ever sees the request, as this part is handled by the operating system itself. Newer versions of TLS may allow the hostname (which is sent in the headers of an HTTP or HTTPS request) to be sniffed so that different certificates can be used for the encryption, even on the same IP address and port. The IIS management interface makes the configuration of certificates appear as if they are part of IIS, but it's not.
Next, IIS receives the HTTP or HTTPS request from the operating system. IIS looks at the bindings for every site (sometimes also referred to as Website by IIS tools) and finds all the ones whose IP address and port match. If there is more than one, chooses the one with a matching hostname (using the Host header in the request, which the browser populates with the hostname from the URL). The hostname cannot contain wildcards, the IIS management interface will not allow them (even though you can set them using command-line tools, they probably don't work they way you think they do anyway, so it's best to avoid them for now). The IIS management interface will not let you create more than one binding with the same information (though the command-line tools sometimes let stuff like this slip by, and the results are undefined). A site is really just an organizational construct in IIS. Like a binding, it has configuration information, but there is no code directly associated with a site--the path specified in the site configuration is really the path for the default application within the site.
Now that the site has been determined, IIS must decide which application to send the request to. When a site is created, a default application is also created for the site. IIS first checks for any non-default applications in the site. Each of those applications will be uniquely identified by a path (the default application has no path, or has the "root" path). If the path matches what's at the beginning of the incoming URL, that application is selected, and the most specific (deepest) matching site is selected. If no non-default application matches, the default application is selected.
Now that the application has been determined, IIS must handle the request directly or somehow route the request to the application. If the request is for a static file and you don't have system.webServer/modules/@runAllManagedModulesForAllRequests="true" set in the web.config for the application, IIS (or perhaps ASP.NET within IIS) just returns the file contents with the appropriate content type. If the request is not for a static file (or you've set the web.config to route all requests through your code), IIS looks to see which Application Pool (or AppPool as the command-line tools refer to it) the site is configured to use. It then forwards the request to your application code in a randomly (or perhaps round-robin) selected process from the "web garden" for that Application Pool. The default web garden only has one process. (IIS itself doesn't ever use the term "web garden", but it is used in blog posts by IIS team members--See the "Maximum Worker Processes" setting in Application Pool settings--this is what controls how many processes are in the garden).
Within the process in the web garden, each site lives in its own AppDomain (this is a .NET term referring to a sandbox within a .NET process, although it is often misused to mean an IIS 'Site', and the term 'application domain' is also sometimes used for this, though I've never seen this term used in the IIS management interface or in the command-line tools). Because of how AppDomains work, each instance of the site (each in a different process in the web garden) gets its own static variables. Your site code is free to create more AppDomains as needed, but that's up to you. IIS only creates one in each web garden (Application Pool) process. Technically, the 'World Wide Web' service probably hands the request to the Application Pool process (w3wp.exe) and that process determines the site and AppDomain to pass the request to, but that's an implementation detail that is hidden by IIS, as both the 'World Wide Web' service and the w3wp.exe process are part of IIS. W3wp could examine the headers at this point to see which hostname was specified and call a different AppDomain for each unique hostname at that point, but it doesn't--that would just slow things down. The request may not even have a hostname, as it could have come in with just an IP address.
Once we get to this point, the ASP.NET application life cycle takes over, but that's irrelevant to your question.


Notice that as your request goes through this process, different hostnames may cause them to go to separate AppDomains in separate applications, but they won't go to separate AppDomains in the same application, unless you specifically write code yourself to create those AppDomains and route the requests there.

Vote Up Vote Down