Dispelling SharePoint Myths

Article
08/01/2008

I've heard numerous myths about SharePoint. Some were scary. Others, funny. Regardless, for your reading pleasure, I'm going to spend the next few posts talking about some of my favorites, with an aim to dispell them.

#1 SharePoint Is More Than An ASP.NET Application

SharePoint is a wonderful product. But - and this is important - SharePoint is an ASP.NET application. Repeat after me. SharePoint is an ASP.NET application. Keep repeating that until you believe it.

I can't tell you how many times I'm asked if there is some "secret sauce" involved in turning an IIS web application into a SharePoint web application. There isn't. Let me break it down for you.

In SharePoint 2003, when SharePoint extended an IIS web application, it registered a custom ISAPI filter to intercept page request handling. This, in turn, would be handed to the ASP.NET page processing pipeline for further manipulation before finally returning the requested page or error to the client. The ISAPI extension was a bit of magic, but didn't do anything that a normal ISAPI extension couldn't do. There wasn't anything special about it, other than the fact that it was written for you. That was it.

The ISAPI extension did pose some problems, though. The ISAPI extension had to be the first ISAPI extension in the list of ISAPI extensions executed for a given web application. Getting that ISAPI extension out of order could cause problems if other, "downstream" ISAPI extensions processed things funny. As a result, for SharePoint 2007 the ISAPI extension was removed and a wildcard application map was added that mapped all requests to IIS for a SharePoint extended web application to the ASP.NET page processing pipeline.

Normally, only files that end in a specific extension are mapped to the aspnet_isapi DLL (and thus the ASP.NET page processing pipeline). Things like .aspx, .config files, etc. For a SharePoint extended virtual server, a wildcard mapping is added that maps everything to the ASP.NET engine. In the web.config file for a SharePoint site, two HTTP handlers are added to the ASP.NET engine that enable SharePoint to process the request like a SharePoint request. These two HTTP modules are the SPRequest module and PublishingHttpModule.

Take a look at the web.config file for a SharePoint site. In the HttpModules section, you'll see two entries that look like this:

These two modules obviate the need for the ISAPI extension. This is what enables SharePoint to serve content that isn't stored on the filesystem, like documents, images, pages, etc. These modules intercept the ASP.NET page request and retrieve that data from the SharePoint content database(s) associated with the web application, instead of letting IIS do the heavy lifting by grabbing it from the filesystem.

So, when SharePoint "extends" an IIS web application, what it's really doing is adding a wildcard mapping to the standard ASP.NET processing DLL. All requests get handed to aspnet_isapi.dll, the same DLL that ships with ASP.NET proper and the same DLL that gets a request for one of your normal ASPX pages. SharePoint then drops a web.config file in the IIS web sites directory that adds a few HTTP modules to process the request further, retrieving things from the database, and serving SharePoint content. That's it. That's all there is. Tada. You're done.

#2 You Can't (Or It's Hard To) Host Non-SharePoint Sites Beneath A SharePoint Web Application

See item #1. SharePoint is an ASP.NET application. The same rules apply to all ASP.NET applications. Many people encounter challenges trying to put their own, non-SharePoint ASP.NET application in a virtual directory beneath a SharePoint site. It's broken, you get funny errors, and the like. What's causing this?

Normally, it's just a byproduct of the way web.config files work. Web.config files inherit from each other. So, if you have a SharePoint web application, you create a virtual directory beneath that web application, drop your web.config and such for your custom ASP.NET application in there, what's happening is your web.config file for your custom app is inheriting all the settings specified in the parent web application. Since your app probably doesn't know about many of the SharePoint DLL's, you get a bunch of funny errors because your ASP.NET application is trying to load SharePoint's HTTP modules, configuration sections, and more. The answer? Judicious use of <clear/> statements.

In ASP.NET, all web.config files inherit from something (save the top config file, machine.config). So, when you create a new web application and put your site there, it works, because it's inheriting from the systems machine.config, and you are used to that. Even if you didn't know that that is what it was doing, your app behaves as you'd expect it to because it's grabbing config values that you expect it to have. Ever wonder why you can just type <system.web> in your config file, and ASP.NET knows what to do with that? Believe it or not, there isn't any special processing that the ASP.NET engine does to "know" about a <system.web> config section in a web.config file. The configuration handler for a <system.web> section is defined in the machine.config file on the system. This is the same syntax and approach that you would use to declare your own custom configuration section, and the same syntax and approach that SharePoint uses to defines its custom sections (i.e. the SafeControl section). For more information on custom configuration sections, see my MSDN article "Configure This: Parameterize Your Apps Using XML Configuration In The .NET Framework 2.0".

Back to your ASP.NET application that you want to live beneath a SharePoint site. Your app is inheriting a bunch of settings that doesn't make sense for it - things like SafeControl sections, authentication and authrorization sections, site map providers, connection strings, and more. The answer? Take a look at the parent SharePoint web.config, and use <clear/> and <remove/> statements in your web.config to get rid of the settings that you don't need or want. Tada.

A note of caution: if you <clear/>, for example, the connection strings section, know that you are not only clearing the connections strings that SharePoint defined, but you are also clearing the connection strings that the machine.config file defined. The connection strings section has inherited settings all the way to the top, and when you clear it, you clear all inherited configuration values. This might not matter to you, but it's something to watch.

That's it for now. I'll post more later, as I've got myself a ton of these!

Dispelling SharePoint Myths

Additional resources