I have worked with many organizations building web based applications on the SharePoint Technologies platform. We have used tools such as Visual Studio, Front Page and, now, SharePoint Designer. Equally important, I present at a number of SharePoint summits across North America. The presentations delivered range from Designing and Implementation – of the various SharePoint related solutions – to branding – using SharePoint Designer. So, it is safe to say that I have quite a bit of experience in working with customers that are resistant to using SharePoint Designer as a customization (some would say branding) tool.
Many of those customers and attendees moved from the Windows SharePoint Services 2.0 platform to the Windows SharePoint Services 3.0 platform. Not only did they migrate the content, but also the skepticism associated with customizing the pages in a SharePoint environment. Or, they have heard about the nightmares associated with rendering customized - back then called unghosting - pages.Therefore, I decided to blog about the new features provided by the ASP.NET 2.0 framework and how it eliminates the problems experienced in the Windows SharePoint Services 2.0 environment. That is, Windows SharePoint Services 2.0 – due to the limitations of ASP.NET 1.1 – had a difficult time parsing pages from the database. As a result, all user requests - for SharePoint sites - were routed to the SQL Server database. All together, that means that Windows SharePoint Services 2.0 had a difficult time parsing and caching pages on the Web Front End servers.
For all that, Windows SharePoint Services 3.0 integration with ASP.NET 2.0 has been completely redesigned. First, Windows SharePoint Services 3.0 is built on ASP.NET 2.0, which provides significant enhancements over ASP.NET 1.1. Furthermore, the routing infrastructure was improved by removing the ISAPI filter and by adding an HttpModule and an HttpHandler that are registered with ASP.NET using entries in the web.config file.
When a SharePoint Administrator creates a Web Application, the SharePoint Administrator is extending an IIS web site to function as a Web application. Also, Windows SharePoint Services 3.0 adds a wildcard application map to the IIS Metabase file.
That is, all incoming HTTP requests are always processed by the ASP.NET runtime environment and are fully initialized with the ASP.NET context before the HTTP Requests are forwarded to the code that processes all Windows SharePoint Services 3.0 related requests. For the most part, the map routes are due to the wildcard application maps in the IIS Metabase. As a result, all incoming HTTP requests to the ASP.NET runtime- regardless of file types .pdf, .doc, … etc
Overall, the ASP.NET 2.0 framework addressed a number of gaps from the previous – Windows SharePoint Services 2.0 - version of SharePoint Technologies. The most notable gap addressed by the newASP.NET architecture addressed the gap related to how .aspx pages are parsed and compiled. The problem in SharePoint Technologies was that it could not leverage the .aspx page parser used by ASP.NET 1.1. The fact that Windows SharePoint Services 2.0 stored .aspx pages in the SQL Server database presented a problem. ASP.NET 1.1 worked only with pages that reside on the local file system of Web Front End servers. As a result, Windows SharePoint Services could not take advantage of the ASP.NET 1.1 page parser.
Virtual Path Providers were introduced in the ASP.NET 2.0 framework. The new framework allowed developers to write their own custom virtual providers. The value add allowed the SharePoint Product team to write a customized virtual provider – SPVirtualPathProvider - that retrieves .aspx pages from the SQL Server Database. Also, the PageParserFilter affords the SPVirtualPathProvider the capability to control how pages are parsed and compiled.
Once the SPVirtualPathProvider retrieves a .aspx page from the SQL Server database it leverages the ASP.NET 2.0’s .aspx parser. So then, Windows SharePoint Services 3.0 does not fall victim to the performance reduction, with respect to the limited page parsing, experienced by the Windows SharePoint Services 2.0 environment.
Figure 1 Page Rendering Using the SPVirtualPathProvider
In simplier terms, the perceived problems with customizing pages in a SharePoint environment has been addressed from page rendering view point. Despite the negative perception of the ASP.NET 1.1 limitations and how it affected the page rendering in the Windows SharePoint Services 2.0 environment, I think that it is time for the masses to accept the fact that ASP.NET 2.0 addressed those limitations. Whether pages are rendered from the Web Front End file system or from the SQL Server Database, ASP.NET 2.0 ensures that all pages are properly parsed.
That is just my $19.11 worth....