Microsoft SharePoint Foundation as an ASP.NET Application
Applies to: SharePoint Foundation 2010
This topic explains how Microsoft SharePoint Foundation is built on a set of modifications of the Integrated Request Pipeline of Internet Information Services (IIS) and Microsoft ASP.NET.
Note
This topic describes how IIS and ASP.NET operate in integrated mode. They can also operate in classic mode, but because SharePoint Foundation Web applications must be in application pools that use integrated mode, there is no further discussion of classic mode in this topic.
Note
Although this topic discusses web.config files and related files, it is not about customizing these files. For information about customizing SharePoint Foundation configuration, see Working with Web.config Files.
IIS and ASP.NET Configuration
Configuration settings for IIS, ASP.NET, and the Web sites, applications, and services that are built on them, are stored in a hierarchy of configuration files. The general principle is that each file in the hierarchy has a narrower scope than the files above it, and can override, within its scope, settings in files that are higher in the hierarchy. It is also possible to lock some of its settings in one of these configuration files. This prevents files that are lower in the hierarchy from overriding those locked settings.
At the top of the hierarchy is the machine.config file, which is located in the %WinDir%\Microsoft.NET\Framework64\v2.0.50727\CONFIG\ directory. This file contains server-wide settings.
A second server-wide configuration file is the global web.config file, which is located in the same directory.
Note
SharePoint Foundation 2010 uses Microsoft ASP.NET 3.5, even if a later version of ASP.NET is also installed on the front-end Web server. However, version 3.5 did not change the default machine.config file, or the global web.config file. The most recent preceding version of the application that did change these files is Microsoft ASP.NET 2.0; for this reason, the files are located under the version 2.0 branch of the %WinDir%\Microsoft.NET\Framework64\ folder.
A third server-wide configuration file is the IIS configuration store, which is housed in the applicationhost.config file. This file is located in the %WinDir%\System32\inetsrv\config\ directory and it contains registrations of the IIS Web sites and application pools on the server, as well as some settings that apply to all Web applications on the Web server. The settings in applicationhost.config are primarily oriented to the parts of the pipeline that are contributed by IIS, whereas the machine.config and the global web.config files contain settings that are primarily oriented to the parts of the integrated request pipeline that are contributed by ASP.NET.
Each IIS Web site can have its own web.config file at its root that contain site-specific overrides of the settings that are inherited from configuration files that are higher in the hierarchy and to add new settings.
Particular physical or virtual directories in an IIS Web site can also have their own web.config file to add new settings or override inherited settings. The new settings and overrides, of course, apply only to HTTP requests for resources located within the directory and its subdirectories.
Note
A ‘Web application’ in SharePoint Foundation terminology is closely related to what is called a ‘Web site’ in IIS terminology. Every SharePoint Foundation Web application is hosted in an IIS Web site with the same name and usually in only one IIS Web site. (It is possible, however, to extend a SharePoint Foundation Web application to an additional port, in which case it is hosted in an additional IIS Web site). For this reason, you may see references in SharePoint Foundation documentation to the root web.config file of a Web application or to a web.config file in a directory of a Web application. What is actually being referred to, strictly speaking, are the roots and directories of the corresponding IIS Web site.
The XML schema that is used by these configuration files is described at IIS 7.0: Settings Schema. See also ASP.NET Configuration Overview and The Configuration System in IIS 7.0.
The Request Pipeline
When a front-end Web server receives a request from a client, the request is passed through a pipeline of units that process the request. This processing includes authenticating the user, verifying the user’s authorization, building the response, sending the response, and finally, logging the request. Historically, some of these units originated in earlier versions of IIS and others in ASP.NET, but the distinction in origins is of little importance to SharePoint Foundation.
HTTP Handlers
The response to any request is produced by an HTTP handler object. Requests are assigned, by the *.config files, to one or another HTTP handler object (or to a handler factory class that creates HTTP handler objects) depending on the resource requested and the HTTP verb in the request. For example, in an unmodified ASP.NET installation, a request for an aspx file; that is, an ASP.NET page, with the verb "GET" is sent to a PageHandlerFactory object that creates an Page object to handle the request. Only classes that, like the Page class, implement the IHttpHandler class can be managed code HTTP handlers. The mapping of a resource/verb pair to a handler (or a handler factory) is specified in the handlers child element of the system.webServer element. The following is an example of the handlers element, with most of the child elements omitted for brevity.
<location path="" overrideMode="Allow">
<system.webServer>
<handlers accessPolicy="Read, Script">
...
<add name="PageHandlerFactory-Integrated" path="*.aspx" verb="GET,HEAD,POST,DEBUG"
type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode" />
<add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="GET,HEAD,POST,DEBUG"
type="System.Web.UI.SimpleHandlerFactory" preCondition="integratedMode" />
<add name="WebServiceHandlerFactory-Integrated" path="*.asmx" verb="GET,HEAD,POST,DEBUG"
type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
preCondition="integratedMode,runtimeVersionv2.0" />
...
</handlers>
...
</system.webServer>
</location>
The overrideMode attribute of the location element is set to "Allow" so that *.config files lower in the hierarchy can have handler elements of their own that override the settings here. The path attribute is set to the empty string so these settings then apply to all IIS Web sites unless they are overridden in a *.config file.
HTTP Modules
The request pipeline also contains HTTP modules. Modules are assemblies that typically contain one or more event handlers or define new events that other modules can handle. An HTTP module can register for one or more events in the lifecycle of the request. There are often used to preprocess or post process requests. The default modules are registered in a modules child element of the system.webServer element. The following is the default modules element, with most of the child elements omitted for brevity.
<location path="" overrideMode="Allow">
<system.webServer>
...
<modules>
...
<add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule"
preCondition="managedHandler" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"
preCondition="managedHandler" />
...
<add name="RoleManager" type="System.Web.Security.RoleManagerModule"
preCondition="managedHandler" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"
preCondition="managedHandler" />
...
<add name="UrlMappingsModule" type="System.Web.UrlMappingsModule"
preCondition="managedHandler" />
...
</modules>
</system.webServer>
</location>
The preCondition attribute specifies a condition that a request must meet before the module is applied to it. When the attribute has the value "managedHandler", then the module is applied to requests for managed resources (which are primarily ASP.NET types of resources, such as aspx files). The section How SharePoint Modifies the Pipeline below describes how SharePoint Foundation overrides this behavior so that these modules apply to all requests, even to non-ASP.NET types of resources such as static HTML files. For more information about HTTP modules see Introduction to IIS 7.0 Architecture.
Why SharePoint Modifies the Pipeline
Here is a list of reasons why the goals of SharePoint Foundation require it to change the default configuration of the pipeline:
SharePoint Foundation creates a new, abstract Web world in which lists and list items, instead of pages, are the primary entities in the population. Of course, viewing and interacting with this population, at least through a browser, requires that the data be implemented on top of the familiar Web world of browser-rendered pages. But the lists exist independently of any particular page and a particular list can appear on more than one page. For this reason, the page structure of a Web site has reduced importance in SharePoint Foundation for many purposes.
Consider one implication of having Web sites structured around lists instead of pages. A site map that shows the structure of pages is of much less interest than one that maps the lists. For this reason, a list content site map is of much greater use than a site pages map.
ASP.NET request handlers generally, if not universally, assume that the URL of a requested resource maps directly into the file system of the front-end Web server. But SharePoint Foundation stores many resources, such as customized pages, in a database. Also, even when a file is located in the file system of the front-end Web server, SharePoint Foundation makes extensive use of virtual directories, beyond just the default IIS mapping of the server’s virtual root "\" to the physical directory "inetpub\wwwroot\". Among other reasons, this technique is needed to make SharePoint Foundation application pages a part of every Web site within a SharePoint Foundation Web application.
By default, the modules in the pipeline that are contributed by ASP.NET, such as the FormsAuthentication module, only process ASP.NET-related resource types, such as aspx files. But there is no limit to the types of files that can be stored in a SharePoint Foundation document library; SharePoint Foundation needs all requests, regardless of the resource type, to be processed by these modules. For example, if a user receives an e-mail with a link to a .docx file in a SharePoint Foundation document library, that user must be authenticated before he or she can access the file.
By default, ASP.NET compiles every aspx page into an assembly loaded in memory the first time it is requested. SharePoint Foundation deployments generally have too many aspx pages to make this feasible; the memory of front-end Web servers would become choked and there is no way to unload dynamically these assemblies from memory. Hence, SharePoint Foundation must serve most aspx pages in decompile mode.
SharePoint Foundation enables delegation of administration. Although servers and farms are still administered by IT workers, many tasks that would traditionally be considered the work of IT professionals or Web site designers, such as the creation of new Web sites and site pages, is handled in SharePoint Foundation by users who would be considered amateurs from the perspective of IT professionals. Delegating authority to non-professionals requires a more complex pattern of trust and permission control.
The ASP.NET design generally assumes that new aspx pages are added to a Web site only by people who have an administrator’s permission to add them. Hence, the application trusts any control on any such page. SharePoint Foundation, however, allows a much wider range of end users to add aspx pages: anyone with the Add and Customize Pages permission can do it. This requires SharePoint Foundation to have a system that enables administrators to limit what controls are allowed on a page. Moreover, since these user-created pages can have Web Parts, administrators need a way to limit the sheer number of Web parts and controls. It is also necessary that user-added controls and Web Parts be limited in what kind of code they can execute to avoid errant code from crashing the web server. SharePoint enforces this by requiring these controls to run in a restricted execution mode called safe mode.
SharePoint Foundation exposes a client object model in an assembly that is installed on client computers. This assembly enables code to be sent to the server and executed in batch mode. This requires a host on the server to handle the batches. There is nothing built into ASP.NET like this. It has no client-side assemblies.
SharePoint Foundation supports workflows and is tightly integrated to Windows Workflow Foundation.
SharePoint Foundation has an extensive system of globalized resources that are referenced in its .aspx and .ascx files. These require specialized expression builders.
ASP.NET support for AJAX was partially redesigned for Microsoft ASP.NET 3.5, and SharePoint Foundation supports the new design with custom handlers.
SharePoint Foundation has a highly configurable request throttling system that enables selective blocking of HTTP requests, when a server is busy, based on the characteristics of the request, such as the identity of the user agent, the type of resource being requested, and information in the header.
SharePoint Foundation enables access to its Web sites from mobile devices. This is accomplished by automatically redirecting requests from mobile devices to special mobile-optimized versions of the Web pages.
How SharePoint Modifies the Pipeline
This section describes how, and where, SharePoint Foundation makes changes to the integrated request pipeline when it is installed. However, only the most significant changes are discussed. The bold numbers in brackets following the itemized changes in the subsections below requirement, in the list underWhy SharePoint Modifies the Pipeline**, is supported by the change.**
Note
In addition to modifying the pipeline, SharePoint Foundation makes other configuration changes to the front-end Web servers when it is installed. For example, it creates IIS Web sites and application pools for a first SharePoint Foundation Web application, for the SharePoint Foundation Central Administration application, and one for the SharePoint Services Platform. (The last of these Web site and application pools replaces a UDDI Web site and application pool that is deleted by the installation of SharePoint Foundation.) It also creates application pools to support the Business Data Connectivity (BDC) service, security tokens, and claims-based security. These other changes are also persisted in the hierarchy of configuration files, but they are not discussed here.
Pipeline Changes at the ASP.NET Framework Level
None. SharePoint Foundation makes no changes to the machine.config file or the global web.config file.
Pipeline Changes at the IIS Configuration Level
SharePoint Foundation changes the IIS configuration store (applicationhost.config). The most significant changes are the following:
SharePoint Foundation registers owssvr.dll as a global module named SharePoint14Module. This unmanaged assembly is a primary means by which requests for data are transmitted from the front-end Web servers to the SharePoint Foundation databases. It handles requests to a SharePoint Foundation Web application for unmanaged resources. (ASP.NET resources, such as as?x files, are managed resources.) Registering an unmanaged assembly makes it available for particular IIS Web sites (and, thus, SharePoint Foundation Web applications) to enable for their own use. (Managed modules do not have to be registered globally.) For more information about owssvr.dll, see Remote Procedure Call Protocol and its child topics. The following shows the registration. (Line breaks in the path are not in the original.) [2 and 3]
Note
All excerpts from SharePoint Foundation configuration files in this topic were taken from a pre-release version of SharePoint Foundation. They are provided for purposes of illustration and do not necessarily show the contents of the files in the released product.
<system.webServer> ... <globalModules> ... <!-- Other Unmanaged Modules --> ... <add name="SharePoint14Module" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\owssvr.dll" /> </globalModules> </system.webServer>Some IT departments want to restrict the ISAPI extensions that can run on their servers to those that are specifically itemized in a <isapiCgiRestriction> section of the applicationhost.config file. To accommodate this policy, SharePoint Foundation adds owssvr.dll and three closely related assemblies to this section. The following shows the registration. (Line breaks in the path are not in the original.) [2]
<system.webServer> ... <security> ... <isapiCgiRestriction notListedIsapisAllowed="false" notListedCgisAllowed="false"> ... <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\_vti_aut\author.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\_vti_adm\admin.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\shtml.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\owssvr.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> </isapiCgiRestriction> ... </security> ... </system.webServer>A <site> section is created in applicationhost.config whenever SharePoint Foundation creates an IIS Web sites and application pool for a SharePoint Foundation Web application. The main purpose of this section is to map virtual directories to physical directories with virtualDirectory elements. The following is an excerpt from a <site> section. (Line breaks in the paths are not in the original.) [2]
<site name="SharePoint - 80" id="2055865624" serverAutoStart="true"> <application path="/" applicationPool="SharePoint - 80"> <virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot\wss\VirtualDirectories\80" /> <virtualDirectory path="/_vti_bin" physicalPath="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\isapi" /> <virtualDirectory path="/_layouts" physicalPath="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\template\layouts" /> <virtualDirectory path="/_controltemplates" physicalPath="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\template\controltemplates" /> ... </application> ... </site>
Pipeline Changes at the SharePoint Web Application Level
When a SharePoint Foundation Web application (and a corresponding IIS Web site) is created, a web.config file is added to its root. This file contains the following configuration settings, which add to, or override, the settings made at higher levels in the configuration hierarchy. For more information about this file and how it can be modified in SharePoint Foundation development projects, see Working with Web.config Files.
A <SafeMode> section configures the safe mode processing system. The following is the standard SharePoint Foundation SafeMode element immediately after installation. Note the CallStack attribute is set to false. The effect of this is to block most of the system exception information that ASP.NET would otherwise report. This is done to prevent information disclosure. [5 and 6]
SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false"> ... </SafeMode>A <SafeControls> section specifies the controls that are allowed to run in safe mode. Customized site pages run in safe mode, but application pages do not. This ensures that users cannot add a site page that contains a control that does not have the permission of an administrator to run on a site page. (Users do not have the right to add application pages.) Each SafeControl element in the section can register a particular control class in an assembly as safe, or multiple classes by using wildcards. (You can add additional SafeControl elements of your own to the file as part of the deployment of your development project. For more information about how to do this, see How to: Create a Supplemental .config File and SafeControl Element (Solution).) The following is an excerpt from the <SafeControls> section. [5 and 6]
<SharePoint> ... <SafeControls> <SafeControl Assembly="System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.WebControls" TypeName="*" Safe="True" AllowRemoteDesigner="True" /> ... <!-- Other ASP.NET classes --> ... <SafeControl Assembly="System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.WebControls" TypeName="SqlDataSource" Safe="False" AllowRemoteDesigner="False" /> ... <!-- SharePoint classes from earlier versions of the SharePoint assemblies --> ... <SafeControl Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint" TypeName="*" Safe="True" AllowRemoteDesigner="True" /> ... <!-- Other SharePoint classes from the current version of the SharePoint assemblies --> ... <SafeControl Src="~/_controltemplates/*" IncludeSubFolders="True" Safe="True" AllowRemoteDesigner="True" /> ... </SafeControls> ... </SharePoint>Notice that the last SafeControl element in the excerpt registers as safe the uncompiled ascx controls in the virtual directory _controltemplates, which maps to %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\CONTROLTEMPLATES directory.
A <pages> section is added that identifies the custom SharePoint Foundation page parser filter (derived from PageParserFilter) that screens for unsafe controls. The filter also determines if the page should be compiled or served in no compile mode. The registration is shown in the following. [4, 5, and 6]
<pages enableSessionState="false" enableViewState="true" enableViewStateMac="true" validateRequest="false" pageParserFilterType="Microsoft.SharePoint.ApplicationRuntime.SPPageParserFilter, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" asyncTimeout="7"> ... </pages>A <modules> section overrides the inherited configuration in the following ways:
The runAllManagedModulesForAllRequests attribute is set to true. This has the effect of overriding the "managedHandler" precondition set in the IIS configuration store and, so, the managed code parts of the pipeline (including those that are contributed by ASP.NET, such as authentication of the user) apply to all requests, regardless of whether the resource that has been requested is of a managed type or whether it has any particular association to ASP.NET. [3]
Some modules that SharePoint Foundation does not use are removed and others are added, including SharePoint14Module, which is another name for the owssvr.dll file. (This unmanaged module is registered in the IIS configuration store as a global module. It also must be enabled here for use by this Web application.) [2]
SPRequestModule is also added. This managed module performs the following tasks:
Registers the SharePoint Foundation virtual path provider, an object of an internal class that implements VirtualPathProvider. The path provider serves as an URL interpreter. For example, if a request is received for a site page that the site owner has customized, the URL appears to point to a location in the physical file system; but the SharePoint Foundation path provider translates the URL to a location in the content database. The path provider also enables SharePoint Foundation to support two different kinds of URLs: server-relative and site-relative. It resolves the "~" tokens that appear in certain file paths, such as the paths for master page files. It checks whether a requested file in a document library is checked out. Finally, the path provider interprets URLs containing virtual folders and resolves them to the actual physical URL. When the path provider has retrieved an aspx page, it passes it to the page parser filter, which determines whether it contains unsafe code. If it does not, then the file is passed to the ASP.NET page parser. [2]
Determines whether a request should be routed to owssvr.dll and, if so, it does some processing of the HTTP headers in the request that is needed by owssvr.dll. [2 and 3]
Governs the performance monitoring and request throttling system. It can selectively block requests when a server is too busy to handle all the requests it is receiving. [11]
Determines if the request is from a mobile device. If it is, the request is forwarded to the appropriate mobile page. [12]
The following shows the <modules> section.
<system.webServer> ... <modules runAllManagedModulesForAllRequests="true"> <remove name="AnonymousIdentification" /> <remove name="FileAuthorization" /> <remove name="Profile" /> <remove name="WebDAVModule" /> <add name="SPRequestModule" preCondition="integratedMode" type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add name="SharePoint14Module" preCondition="integratedMode" /> </modules> ... </system.webServer>
A <handlers> section overrides the inherited configuration mainly by removing some HTTP handlers that SharePoint Foundation does not use and by adding handlers that support AJAX. Also, owssvr.dll is registered as an HTTP handler under the name OwssvrHandler. This is necessary so that requests can be routed to it during the MapRequestHandler event. (Requests for unmanaged resources are handled by OwssvrHandler.) For more information about the events in the request lifecycle, see ASP.NET Application Life Cycle Overview for IIS 7.0. The following shows the <handlers> section. (Line breaks in paths are not in the original.) [3 and 10]
<system.webServer> ... <handlers> <remove name="OPTIONSVerbHandler" /> <remove name="WebServiceHandlerFactory-Integrated" /> <remove name="svc-Integrated" /> <remove name="WebDAV" /> <add name="svc-Integrated" path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode" /> <add name="OwssvrHandler" scriptProcessor="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\isapi\owssvr.dll" path="/_vti_bin/owssvr.dll" verb="*" modules="IsapiModule" preCondition="integratedMode" /> <add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> </handlers> </system.webServer>A <microsoft.sharepoint.client> section is added to support the client object model of SharePoint Foundation and client-side programming. (For more on this object model, see Using the SharePoint Foundation Client APIs.) The following markup shows this section. [7]
<microsoft.sharepoint.client> <serverRuntime> <hostTypes> <add type="Microsoft.SharePoint.Client.SPClientServiceHost, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </hostTypes> </serverRuntime> </microsoft.sharepoint.client>Several sections are added to support limits on the Web Parts and the number of controls. [5 and 6]
<WebPartLimits MaxZoneParts="50" PropertySize="1048576" /> <WebPartCache Storage="CacheObject" /> <WebPartControls DatasheetControlGuid="65BCBEE4-7728-41a0-97BE-14E1CAE36AAE" />A <WorkflowServices> section and a <System.Workflow.ComponentModel.WorkflowCompiler> section are added to support workflows in SharePoint Foundation. The following markup shows the <WorkflowServices> section and below that, an excerpt from the <System.Workflow.ComponentModel.WorkflowCompiler> section.[8]
<SharePoint> ... <WorkflowServices> <WorkflowService Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Class="Microsoft.SharePoint.Workflow.SPWinOEWSSService"> </WorkflowService> <WorkflowService Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Class="Microsoft.SharePoint.Workflow.SPWinOETaskService"> </WorkflowService> </WorkflowServices> </SharePoint> ... <System.Workflow.ComponentModel.WorkflowCompiler> <authorizedTypes> <authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="*" Authorized="True" /> <authorizedType Assembly="System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="*" Authorized="True" /> <authorizedType Assembly="System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.Runtime" TypeName="CorrelationToken" Authorized="True" /> <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System" TypeName="Guid" Authorized="True" /> ... <-- Other mscorlib classes --> ... <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowActivationProperties" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowTaskProperties" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowHistoryEventType" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPItemKey" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowUserContext" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WorkflowActions" TypeName="*" Authorized="True" /> </authorizedTypes> </System.Workflow.ComponentModel.WorkflowCompiler>A <securityPolicy> section is used to add two additional trust levels, WSS_Minimal and WSS_Medium. These trust levels are defined in files located at %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG directory. The following markup shows the <securityPolicy> section. (Line breaks in paths are not in the original.) [5]
<system.web> <securityPolicy> <trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\config\wss_mediumtrust.config" /> <trustLevel name="WSS_Minimal" policyFile="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\config\wss_minimaltrust.config" /> </securityPolicy> ... </system.web>A <compiliation> section notifies the page parser of four additional assemblies it can use for compiling SharePoint Foundation as?x files. It also specifies four special expression builders that the page parser uses to process ASP.NET pages and other as?x controls in a SharePoint Foundation Web application. The following markup shows the <compiliation> section. [9]
<system.web> ... <compilation batch="false" debug="false"> <assemblies> <add assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add assembly="Microsoft.SharePoint.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </assemblies> <expressionBuilders> <remove expressionPrefix="Resources" /> <add expressionPrefix="Resources" type="Microsoft.SharePoint.SPResourceExpressionBuilder, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add expressionPrefix="SPHtmlEncodedResources" type="Microsoft.SharePoint.SPHtmlEncodedResourceExpressionBuilder, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add expressionPrefix="SPSimpleFormattingEncodedResources" type="Microsoft.SharePoint.SPSimpleFormattingEncodedResourceExpressionBuilder, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add expressionPrefix="SatelliteResources" type="Microsoft.SharePoint.Search.SPSatelliteResourceExpressionBuilder, Microsoft.SharePoint.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </expressionBuilders> </compilation> ... </system.web>A <sitemap> section specifies four special SharePoint Foundation site map providers. The following markup shows the <sitemap> section. [1]
<system.Web> ... <siteMap defaultProvider="SPSiteMapProvider" enabled="true"> <providers> <add name="SPNavigationProvider" type="Microsoft.SharePoint.Navigation.SPNavigationProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="SPSiteMapProvider" type="Microsoft.SharePoint.Navigation.SPSiteMapProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="SPContentMapProvider" type="Microsoft.SharePoint.Navigation.SPContentMapProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="SPXmlContentMapProvider" siteMapFile="_app_bin/layouts.sitemap" type="Microsoft.SharePoint.Navigation.SPXmlContentMapProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </providers> </siteMap> ... </system.Web>
Note
The SharePoint Foundation Central Administration Application is implemented as a SharePoint Foundation Web application; and, thus, as an IIS Web site. It, too, has a root web.config file that is very similar to the web.config described above. The main differences are that the Central Administration Application supports session states and registers additional site map providers and some additional controls as safe. The IIS Web site that hosts the SharePoint Services Platform also has a very small root web.config. It is used to register providers that support claims-based security.
Pipeline Changes at the Directory Level
SharePoint Foundation further refines the request pipeline with web.config files that apply only to requests for resources within particular physical or virtual directories. Just one example is given here: SharePoint Foundation provides versions of its application pages and forms that are designed for viewing on mobile devices. These are located in the virtual directory _layouts\mobile (which is mapped to the physical directory %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS\MOBILE\). That directory contains a web.config file that sets limits on how much data is displayed on the page. It also registers a series of filters that control how the page is rendered, based on the capabilities of the mobile device that has requested the page.
See Also
Other Resources
ASP.NET Application Life Cycle Overview for IIS 7.0
ASP.NET Configuration Overview