Introduction
The configuration system in IIS 7.0 is significantly different than in previous versions of IIS, and builds on top of some (but not all) of the concepts of the .NET framework configuration system. Its scope spans across the entire web server platform (IIS, ASP.NET) and serves as the core of the all-new IIS 7.0 administration "stack". This document walks through the design and architecture of the configuration system, and introduces the programmable interface to the system at the lowest-level, native-code, entry point.
This article contains:
There are very few "moving parts" at runtime that implement the configuration system. The configuration system is implemented as a library that runs in-proc in the client application, and interacts with a persistent store on-disk. The store is simply a file, or a set of files, on the file system. The format of the files is XML. Users can edit the files manually at any time, if they choose to, and changes are automatically picked up by the system. There are no proprietary models for doing standard operations like protecting the settings, backing them up, moving them around, or even extending the system with new settings. The system relies heavily on the file system, to simplify tasks such as deploying configuration for web applications and services.
Note: There is no centralized configuration service as in previous versions of IIS. This allows for a significant performance improvement when reading large chunks of data from the store, especially at startup, since there is no inter-process communication and buffer-copy that needs to occur.
Out of the box, after installing IIS, there are several consumers of configuration:
- WAS (Windows Activation Service): Reads global defaults for application pools, sites, and other settings.
- Web server core and modules in the worker processes: When activated to process a request, read configuration settings that control their behavior.
- WMI provider: The IIS 7.0 scripting interface provider is using the configuration system internally to get and set settings.
- AppCmd.exe: The IIS 7.0 command-line tool is using the configuration system internally to get and set settings.
- UI: The IIS 7.0 administration framework is using the configuration system internally to get and set settings.
- Legacy: Applications and scripts that use interfaces such as ABO, ADSI and the IIS 6.0 WMI provider, use the configuration system indirectly, via a component that maps the legacy ABO APIs and model to the new configuration model. The state always persists into the new configuration system.
There are several interfaces that provide access to the configuration settings:
|
Interface |
Access To |
|
Manual editing of the files using a text editor, or maybe via a script. |
All configuration files, if file ACLs permit. |
|
Configuration APIs in native-code and managed-code. |
All configuration files, if file ACLs permit. |
|
Higher-level abstractions on top of configuration system such as the IIS 7.0 WMI scripting provider, UI, or appcmd.exe tool. |
All configuration files, if file ACLs and UI delegation policy permit. |
|
Legacy IIS interfaces such as ABO, ADSI, IIS 6.0 WMI provider. |
Only the root IIS configuration file, and only the legacy (IIS 6.0) settings. .NET framework settings and new IIS 7.0 settings are not exposed to these interfaces. |
|
Legacy .NET framework interfaces such as System.Configuration. |