Integration of Windows Sharepoint Services 3.0 with Asp.net 2.0

Windows SharePoint Services 3.0 provisioning starts at the level of the IIS Web site. Before you can create your first Windows SharePoint Services site, someone must run an administrative procedure to extend 3.0 functionality onto one or more IIS Web sites. In Windows Share- Point Services 2.0, the term virtual server was used to describe an IIS Web site that had been extended with Windows SharePoint Services functionality. To avoid confusion with another Microsoft product of the same name, the Windows SharePoint Services 3.0 documentation now refers to an IIS Web site extended with Windows SharePoint Services functionality as a Web application.

Windows SharePoint Services 2.0 was integrated with IIS 6.0 and ASP.NET 1.1 using an ISAPI filter DLL. This integration technique results in IIS routing requests to Windows SharePoint Services before ASP.NET. This routing has proven to be problematic in certain situations because Windows SharePoint Services takes control of an incoming HTTP request before it has a chance to be properly initialized with ASP.NET context.

The way in which Windows SharePoint Services 3.0 integrates with ASP.NET has been completely redesigned. First of all, Windows SharePoint Services 3.0 is built upon ASP.NET 2.0, which provides significant enhancements over ASP.NET 1.1. Furthermore, the integration between Windows SharePoint Services 3.0 and ASP.NET 2.0 was changed to route incoming requests through the ASP.NET runtime before Windows SharePoint Services. The Windows SharePoint Services team achieved these improvements to the routing infrastructure by removing the ISAPI filter and adding an HttpModule and an HttpHandler that are registered with ASP.NET using standard Web.config entries. This means incoming HTTP requests always enter the ASP.NET run-time environment and are fully initialized with ASP.NET context before they are forwarded to the code written by the Windows SharePoint Services team to carry out Windows SharePoint Services–specific processing.

Also note that when you extend an IIS Web site to become a Windows SharePoint Services Web application, Windows SharePoint Services 3.0 adds a wildcard application map to the IIS metabase. This wildcard application map serves to route all incoming HTTP requests to the ASP.NET runtime regardless of their extension. This wildcard application map is necessary to forward a request for any type of file (for example, .pdf, .doc, .docx) to ASP.NET, which then forwards the request to Windows SharePoint Services for processing.

Another relevant issue of the new architecture has to do with how .aspx pages are parsed and compiled. The .aspx page parser used by ASP.NET 1.1 works only with .aspx pages that reside on the local file system. However, Windows SharePoint Services architecture relies on storing .aspx pages inside a SQL Server database. Since Windows SharePoint Services 2.0 relies on ASP.NET 1.1, the Windows SharePoint Services team had to create their own .aspx page parser. Unfortunately, the .aspx parser of Windows SharePoint Services 2.0 does not support many of the richer features offered by the ASP.NET .aspx page parser.

ASP.NET 2.0 introduced a new pluggable component type known as a virtual path provider. A developer can write a custom component that retrieves .aspx pages for any location including a database such as SQL Server. Once a custom virtual path provider retrieves an .aspx page, it can then hand it off to ASP.NET to conduct the required parsing and compilation. ASP.NET also gives the virtual path provider a good deal of control as to how .aspx pages are parsed and whether they are compiled or run in a non-compile mode.

The Windows SharePoint Services 3.0 team has created their own virtual path provider named SPVirtualPathProvider, which is shown in Figure 1-1 on the next page. As you can see, the SPVirtualPathProvider is able to retrieve .aspx pages from SQL Server and then hand them off to the .aspx page parser supplied by ASP.NET 2.0. That means the Windows SharePoint Services 3.0 team was not required to evolve their .aspx page parser from the previous version. It also means that Windows SharePoint Services 3.0 does not suffer from a reduced feature set with respect to page parsing as it does with Windows SharePoint Services 2.0.

If you’re familiar with the architecture of Windows SharePoint Services 2.0, you’ve probably heard the terms “ghosting” and “unghosting” used in conjunction with the .aspx pages of a Windows SharePoint Services 2.0 site. Page ghosting is a Windows SharePoint Services feature that allows a front-end Web server to store an .aspx page template on its local file system and to share that page template across many different sites. Page ghosting offers performance benefits because Windows SharePoint Services can serve up pages for thousands of sites using a page template stored on the local file system and loaded into memory a single time.

Windows SharePoint Services 2.0 supports user modifications to the page template using tools such as Microsoft Office FrontPage 2003. Once a user modifies a page template and saves the changes, a customized version of the page is stored on SQL Server for that particular site. In Windows SharePoint Services 2.0, this is often referred to as unghosting a page.

Windows SharePoint Services 3.0 still supports page templates that live on the Web server as well as customized versions of those page templates that are stored on SQL Server. However, the Windows SharePoint Services team and their documentation have stopped using the terms ghosting and unghosting because they do not translate well into other spoken languages. In Windows SharePoint Services 3.0, the term “uncustomized page” refers to a page template used directly from the local file system of the Web server, and the term “customized page” refers to a modified version of the page template that has been written to the content database for a particular site.

Another change to be aware of is that Microsoft Office FrontPage 2003 has been renamed in its new release as Microsoft Office SharePoint Designer 2007. Like the previous versions of FrontPage, Office SharePoint Designer 2007 is targeted more toward users than developers. However, it’s nonetheless a handy tool to have in your bag of tricks as a Windows SharePoint Services developer.

Office SharePoint Designer 2007 provides a code editor and WYSIWYG designer for customizing .aspx pages within Windows SharePoint Services 3.0 sites. You can also create new pages within a Windows SharePoint Services site that have no corresponding page template on the Web server. Office SharePoint Designer 2007 supports creating lists and document libraries and even supplies a new wizard for creating custom workflows on a Windows Share- Point Services site. Workflows in Windows SharePoint Services 3.0 will be discussed in more depth later in this article.