Custom Web Applications Coexisting with SharePoint 2007

SharePoint has the concept of managed and unmanaged paths. As the names imply, managed are paths that SharePoint processes and handles such as sites and site collections. Unmanaged on the other hand are those paths that are outside of SharePoint and are not processed by the SharePoint engine. Custom web applications that need to coexist with SharePoint on the same IIS Virtual Server (also referred to as a Web Application in SharePoint speak) typically exist on an unmanaged path.

In 2003, SharePoint allowed paths to be configured as included or excluded. Implicitly and explicitly included paths are still configured at the Web Application level in SharePoint 2007, but excluded paths are no longer declared. This is true using both the SharePoint Central Administration web page and the STSADM SharePoint command line tool. Instead when you create an IIS Virtual Directory, SharePoint treats it as an excluded and unmanaged path.

This works great and reduces administrative overhead with consolidating the two applications on the same IIS Virtual Server. There are however, a couple more steps to take. ASP.NET does a wonderful job constructing a hierarchy of configuration settings. Since the IIS Virtual Directory for the custom application is below the SharePoint directory in the hierarchy, the custom application will inherit the SharePoint application's Web.config settings. Potentially the configuration settings there might conflict with the desired or assumed configuration of the custom ASP.NET application.

A close look at the Web.config for the SharePoint application shows the httpHandlers section specifically set for SharePoint. These changes configure the SPHttpHandler object to handle requests so the SharePoint engine can process requests based on virtual paths constructed in memory from content stored in the SQL Server database as opposed to the file system. Often this extra processing is not required in custom web applications. In those cases using the ASP.NET CustomPageHandlerFactory object instead would be more efficient.

To revert back to default ASP.NET handlers for ASP.NET web pages and web services, make the following changes to the httpHandlers section of the Web.config of the custom web application:

<httpHandlers>

<clear/>

<add
verb="*"
path="*.aspx"

    type="System.Web.UI.PageHandlerFactory"/>

<add
verb="POST,GET"
path="*.asmx"

type="System.Web.Services.Protocols.WebServiceHandlerFactory,System.Web.Services, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

validate="false" />

<!-- Additional handlers as required -->

</httpHandlers>

Edits to the httpModules section in the SharePoint application Web.config include adding the SPRequest and PublishingHttpModule objects. Again, this extra processing is often not needed in custom web applications. The PublishingHttpModule enables or disables ASP.NET output caching for resources in SharePoint and can cause an Event ID 5785 to be wrote to the event log with the description "Unable to connect publishing custom string handler for output caching" when inherited in custom web applications and certain requests like web service calls or static CSS files are made.

To revert back to default ASP.NET modules, make the following changes to the httpModules section of the Web.config of the custom web application:

<httpModules>

    <clear />

<add
name="OutputCache"

type="System.Web.Caching.OutputCacheModule"/>

    <add
name="Session"

type="System.Web.SessionState.SessionStateModule"/>

    <add
name="WindowsAuthentication"

type="System.Web.Security.WindowsAuthenticationModule"/>

    <add
name="FormsAuthentication"

type="System.Web.Security.FormsAuthenticationModule"/>

<add
name="PassportAuthentication"

type="System.Web.Security.PassportAuthenticationModule"/>

    <add
name="UrlAuthorization"

type="System.Web.Security.UrlAuthorizationModule"/>

    <add
name="FileAuthorization"

type="System.Web.Security.FileAuthorizationModule"/>

<!-- Additional modules as required -->

</httpModules>

Another change to make is with the trust level to either increase or further restrict the trust for the custom web application. To override the inherited SharePoint trust level and set the trust level to full trust, make the following changes to the trust node in the Web.config of the custom web application:

<trust
level="Full"
originUrl="" />

Finally, when exposing Web Services through the custom web application, you may need to add the protocols for the Web Service so the application is able to process the request. Requests made on missing protocols throw an InvalidOperationException with the message "Request format is unrecognized for URL unexpectedly ending in '/...'" To add both the Get and Post protocol, make the following changes to the webServices section of the custom web application:

<webServices>

    <protocols>

        <add
name="HttpGet"/>

        <add
name="HttpPost"/>

    </protocols>

</webServices>

Generally I try to keep customizations within SharePoint as much as possible. One technique is to add PageParserPath nodes to the PageParserPaths section of the SharePoint application's Web.config. This will allow server-side code blocks added to custom ASPX pages hosted in SharePoint to execute. Another technique for web services is to deploy them to the ISAPI directory which maps to the _vti_bin IIS Virtual Directory.

Nonetheless, pre-existing custom web applications can quickly be consolidated and coexist with SharePoint applications by including the updates I mentioned throughout this discussion. These updates should help avoid some errors and ease the coexistence challenges.

Comments

• Anonymous
  August 23, 2007
  The comment has been removed

• Anonymous
  May 06, 2008
  The virtual directory under sharepoint should run under the same application pool as sharepoint itself. Specifying different application pool for virtual directory means different process and completely different security privilages. In a way it makes sense to me that it should not be allowed otherwise the underlying application will not run under the same process.

• Anonymous
  June 18, 2008
  The comment has been removed