Feeds:
Posts
Comments

Archive for February 21st, 2011

IIS7 Configuration paths

IIS7, the configuration system stores configuration in a hierarchy of files, starting with 3 root configuration files, and descending into distributed web.config configuration files that can be present in any directory of your website to affect the configuration for the url namespace to which the directory corresponds.  This hierarchy contains the following:

Framework\<version>\CONFIG\machine.config (the .NET framework machine.config file, where most .NET sections are declared)
Framework\<version>\CONFIG\web.config (the .NET framework root web.config file, where most ASP.NET sections are declared)
%windir%\system32\inetsrv\applicationHost.config (the IIS7 global web server configuration file, where all IIS7 configuration sections are declared)
delegated web.config files (the distributed configuration files that can be present in any virtual directory of your site or its subdirectory)

In this system, a configuration path has the following syntax:

MACHINE/WEBROOT/APPHOST/<SiteName>/<VirtualPath>

Where MACHINE, WEBROOT, and APPHOST correspond to the above configuration files, <SiteName> identifies the site, and <VirtualPath> identifies the virtual path.  Note that the site is no longer identified by id, as before, and instead the site name is used (in IIS7, site name is the unique identifier of a site, unlike the ServerComment in IIS6 which was not unique).

Read Full Post »

IIS 7.5 includes a new application as auto-start feature in its ASP.NET 4.0 implementation. This feature enables an administrator to configure an application pool to start up automatically, while temporarily not processing HTTP requests.

This allows applications requiring extensive initialization to finish loading the data they need or to complete other processes before they begin accepting HTTP requests. To use this feature, you must add code like the following to the pool’s applicationHost.config file:

<applicationPools>
<add name=”MyApplicationPool” startMode=”AlwaysRunning” />
</applicationPools>

Read Full Post »

CLR –

Stands for Common Language Runtime (CLR) is a core component of Microsoft’s .NET initiative. It is Microsoft’s implementation of the Common Language Infrastructure (CLI) standard, which defines an execution environment for program code. In the CLR, code is expressed in a form of bytecode called the Common Intermediate Language (CIL, previously known as MSIL—Microsoft Intermediate Language).

CLR diag.svg

Developers using the CLR write code in a language such as C# or VB.NET. At compile time, a .NET compiler converts such code into CIL code. At runtime, the CLR’s just-in-time compiler converts the CIL code into code native to the operating system. Alternatively, the CIL code can be compiled to native code in a separate step prior to runtime by using the Native Image Generator (NGEN). This speeds up all later runs of the software as the CIL-to-native compilation is no longer necessary.

Let see, how this CLR is enabled by administrators to switch versions without modifying the underlying IIS infrastructure. You can specify different CLR settings for individual application pools by creating custom ASPNET.config files. To use these files, you add code specifying their locations to the pool’s applicationHost.config file, as in the following example:

<applicationPools>
<add name=”MyApplicationPool” CLRConfigFile=”c:\InetPub\CLRConfigFile.txt” />
</applicationPools>

The Physical path for ApplicationHost.Config was is %windir%\system32\inetsrv\applicationHost.config

Note: This applicable for IIS 7 and 7.5 versions.

Read Full Post »