I just finished a 6 hour "chase-around" session after what seems to be the most annoying problem I've encountered.
The problem I had was this:
I was using the Virtual PC image that can be downloaded from MSDN Subscriber downloads : it contains the following installed:
- Team Foundation Server RTM
- Windows Sharepoint
- VS 2005
- IIS 6
- Windows Server 2003
Everything is working great out of the box when you use Team System, browse to the team project portal and such, but one little thing.
If you try to build a web site, or a web service, even the most basic "hello world" one, and try to put it in a virtual directory under IIS, you can't navigate to it.
You get weird errors like "404 Page not Found" even though you know the page is there, in local host. Navigating to it from within IIS didn't help either. always the same problem.
Turns out the problem has to do with Sharepoint services and its ISAPI filter.
Sharepoint installs an ISAPI filter in the default web site called "stsfltr". It uses it to intercept all requests to the IIS, find out if they need to be routed to sharepoint sites, or forwarded on..
To do that, it uses a configuration database to locate its settings.
After digging around the system for a while, and doing some brain storming with Justin, we figures out I had two problems:
- I had a login security problem on the configuration server which I had to fix
- I had to tell sharepoint's ISAPI filter to exclude the websites and web services I wanted to expose on IIS. (the link here is from the Internet archive, because the actual blog post is gone. I'll posts parts of it here so that it does not get lost
So, if you're going to expose services and sites from an IIS that also hosts Sharepoint, you'll need to do the following:
Hopefully, that should be it.
for the sake of keeping the information alive, I am copying from the web archive into this blog post from what Maxim Karpov wrote on this, since it's interesting.
Begin Quote from web archive:
IPattern.com (Maxim V. Karpov) .NET patterns, best practices and more...
Thursday, March 18, 2004
SharePoint STSFLTR.DLL dirty secret and more…
Design Patterns: Intercepting Filter, Front Controller
SharePoint 2003 (v2) is a great improvement over the previous version of the product, but it still has a long way to go as far as improving development process. One its major improvements is that the SharePoint team utilized Microsoft SQL Server 2000 engine for the back end storage of settings and user data. Every single article, post, and SDK talks about how STSFLTR.DLL relies on Configuration database to retrieve needed information. Is this completely true?
I was intrigued, but the fact that the default installation of WSS takes over the entire IIS Server by means of ISAPI filter (STSFLTR.DLL that should be named WSSFLTR.DLL) and intercepts every single request- response ultimately prevents us from running IIS virtual directories as ASP.NET Web Applications. The first thing I learned when I started working with SharePoint was how to enable ASP.NET Web Application to be able to execute side by side with SharePoint. The process is as follows:
- Launch the SharePoint Central Administration site
- Click on the Configure Virtual Server Settings.
- Select your Virtual Server.
- Click on the Define Managed Paths link in the Virtual Server Management section.
- Add the path to exclude, pointing to the URL of your custom ASP.NET application
<IMAGE was not found, unfortunately>
By default I have two IIS virtual directories excluded UDDI and UDDIPUBLIC then I added MYASPNETAPP, WEBAPPLICATION, and MYCONTROLS. I can add as many as I want, but for the sake of the demo I will stop at this. My efforts to find where SharePoint stores these exclusions were finally successful after hours of searching Configuration database tables and web.config files. I finally resorted to the last place I wanted to look: Windows Registry. Yes, it is still alive and kicking! Bingo~ after searching within the windows registry, I found the entries as follows:
<IMAGE was not found, unfortunately>
Registry contains Exclusions and Inclusions folders for the managed paths within windows registry and the SharePoint team was nice in providing us with Web UI to allow manipulation of it. I believe the entire core infrastructure of SharePoint was written in the unmanaged code while all of the WSS APIs were written with the .NET framework.
Why would they store this information in the registry? I am not sure and this is good question to ask the SharePoint team. I am still waiting on them to respond to me.
What is STSFLTR.DLL anyway?
It is an ISAPI filter that implements Intercepting Filter Design Pattern, which is written in C++ and provides mechanize of intercepting ALL incoming requests. STSFLTR.DLL deals with handling the requests and making sure that they are passed correctly to the correct HttpHandler.
<IMAGE was not found, unfortunately>
All of the requests are going through the filter unless otherwise specified with the registry modification.
| Files and Directories | ISAPI Extension | SharePointHandlerFactory* | PageHandlerFactory** |
| Web Dev, HTML | X |
|
|
| Front Page RPC | X |
|
|
| /_layouts/*.ASPX |
|
| X |
| /EXCLUDED/*.ASPX |
|
| X |
| /SITES/*.ASPX |
| X |
|
| /INLUDED/*.ASPX |
| X |
|
I have one wish: That Microsoft would document things like this to make our job slightly easier as developers. Don’t you think so?
I hope this installment helped you to understand what is going on under the hood of ISAPI filter framework and how it is intergraded with ASP.NET Http Handlers. I was pleased to find the answer, but at the same time discouraged to see that Microsoft teams are still using so many different places to store configuration data for their applications. Do not blindly follow the instructions to “do it this way” for your answers. It pays off to go the extra mile in order to find out the reason behind the implementation. I was pleased in knowing I could use a Design pattern with a technology product like SharePoint.
Design Patterns are the way to go, don’t you think?
posted @ 5:59 PM Comments[7]
End quote of Maxim Karpov