• Choose a category
• All
• Classic-Fiction

By Root 5412 0

API exposed as a Web service to ASP.NET AJAX applications. The section has three attributes—enabled, readAccessProperties, and writeAccessProperties. The latter two properties consist of a list of comma-separated names of properties to be read and written as part of the user’s profile.

The Section

In general, the section contains site-level settings for IIS 7.x. Defined within the applicationHost.config file and edited via the user interface of IIS Manager, the section specifies any settings used by the Web server engine and modules. Full documentation is available at http://www.iis.net/ConfigReference/system.webServer.

The section can also be used within the application’s web.config file to make some of the settings specific to a given application. There’s a specific situation, though, that requires you to have a section in the application’s web.config file—an ASP.NET application that employs HTTP modules, HTTP handlers, or both and runs under IIS 7.x in integrated mode.

Before IIS 7 came along, any ASP.NET request had to go through two distinct pipelines: one right at the IIS gate, and one mapped to the ASP.NET runtime environment. Subsequently, an ASP.NET application in need of supporting special HTTP modules or handlers simply registered them in the web.config file and waited for them to be invoked. In IIS 7 integrated mode, instead, the request pipeline is unified at the IIS level. As a result, any HTTP handlers and HTTP modules you might have registered in the and sections of the web.config file will be blissfully ignored.

For an IIS 7–integrated ASP.NET application to properly deal with HTTP modules and handlers, you have to move the and sections to a new section in the same application’s web.config file. There are some snags though.

Important

When developing HTTP handlers and modules, you should be aware of a key point. The ASP.NET Development Server (also known as Cassini) doesn’t honor the content of the section. This means that, for development purposes only, you should copy the registration of your handlers and modules also in the and section, regardless of whether your application will actually be deployed on IIS 7. The ASP.NET Development Server that comes with Visual Studio is designed to capture and process all requests within its own pipeline; in this regard, its overall behavior is more similar to IIS 6 than IIS 7.

Under , sections have been renamed and and have a slightly different set of attributes. In particular, each handler must have a name attribute and support additional attributes, namely precondition and allowpolicy. The precondition attribute lists what’s required for the handler to work: type of pipeline (classicMode or integratedMode), bitness (32 or 64), and runtime version of ASP.NET (v2 or v4). The allowPolicy attribute sets the permissions granted to the handler: read, write, execute, or script.

The section counts a couple of Boolean attributes, such as runAllManagedModulesForAllRequests and runManagedModulesForWebDavRequests. Both properties default to false. This is the typical content for in a new ASP.NET 4 application in Visual Studio 2010.

The attribute runAllManagedModulesForAllRequests indicates that all managed modules can process all requests, even if the request was not for managed content. Instead, the attribute runManagedModulesForWebDavRequests specifies whether managed modules can process WebDAV requests.

These differences between classic and integrated mode lead you toward using different web.config files to set up handlers and modules for the same application deployed in different scenarios. By using the element, however, you can have a single web.config file with settings for both classic and integrated IIS 7 working modes: