Welcome to the ASP.NET 2.0 Framework

The new version of WSS, Windows SharePoint Services 3.0, is integrated more tightly with the ASP.NET 2.0 framework model. Similar to the previous versions of SharePoint, the concepts of extending and de-extending websites with the SharePoint framework still exists, meaning that an administrator must still provision the WSS assets onto a an IIS website to have a full fledged WSS site, however the extending process is slightly different and the differences that segregated SPS areas and WSS site collection are now merged into one cohesive unit under site collections.

Got a Blank Site?

For example, after getting my MOSS farm up and running, and the proper services going the way that I wanted them, I was still stuck with a blank site. Usually, after extending a WSS 2.0 IIS server there was a top level site created that was it to create and house a site collection. However, when extending within the new MOSS framework, you firstly create a new web application (which is means extending basically), and then create a new site collection on the portion that is created following that extension (or web application creation as we should start getting used to calling it).

Adios ISAPI

The most interesting, and exciting change to the overall WSS architecture that comes from the change from the integration of the 2.0 framework is the ISAPI filter (STSLTR.DLL) has been gotten rid of. This is interesting in regards to implementing Antigen within an environment. Antigen relies on the ISAPI filter for interception. For example, whenever a document is uploaded or downloaded from a SharePoint site either through the standard SharePoint interface, or through any method through the SharePoint object model, relies on using the ISAPI filter to route documents into a real-time scan engine. It will be interesting to see the next version of Antigen running while this object will either conflict with the new 2.0 handlers or will have to be rebuilt to compensate for it.

What was the big deal with that ISAPI filter in the old version of WSS? The largest issue that came up from developers was developing custom authentication procedures for your WSS site, such as forms based authentication or robust SSO solutions. Typically, to achieve this previously required a developer to write a VC++ filter and extension that would intercept prior to the WSS ISAPI filter so that routines could be injected and incepted because ownership would be given priority to the ISAPI filter, the request would have to be rerouted. But, there has been a shift in how that is handled with the introduction of ASP.NET 2.0 into the SharePoint framework, which is long overdue as someone who has been required to write those same extensions for several previous projects, and they aren’t the most particular exciting piece of business logic to program.

Beneficial Options Brought By the Introduction of the ASP.NET 2.0 Framework

With the change of the framework moving to the 2.0 framework, there are more robust options available to the developer because it is fully managed by the ASP.NET 2.0 provider. For example, to implement forms based authentication in .NET 2.0 previously it required the developer to typically use the IIS 6.0 resource kit and use the customauth provider, which at times depending on environment and client requirements could be a rather arduous task (especially in regards to getting permissions functioning correctly at that level).

ASP.NET 2.0 HTTP Handler and Module

The http handler and module providers allow your SharePoint site to be instead fully managed by an ASP.NET provider, making implementing assets that were previously development heavy quite simple. You can now write code against the SharePoint framework that you would like to be injected by ASP.NET before the page is provided. The varying authentication providers are even provided through a GUI, I find this incredibly useful since several past clients were interested in implementing SharePoint as an externally facing solution. Typically, the NT authentication box was not desirable because it is a rather inelegant, and ugly, solution for signing into what is supposed to be a richly featured ECM and portal. The forms solutions however can be customized and tailored to client needs, and is much more advantageous to making a more applicable environment.

Differences In How WebForms Are Handled

There are obviously several other benefits that stem from SharePoint being integrated with the 2.0 framework. If you have been working with the 2.0 framework for some time, you will have noticed that there is a different way that the WebForms are handled. Leveraging the 2.0 framework eliminates the legacy method of using hundreds of thousands of template forms fronting data being served in order to provide different functionality with the varying datasets. Instead, the WebForms are stored in a SQL database, which drastically cuts down on the amount of WebForms that are required for a SharePoint environment to run correctly.

This may seem unclear still, however it makes more sense when you think about the context o the .aspx provider in both environments, both in the legacy 1.1 environment and the 2.0 framework. In both situations, there were separate objects developed to handled the page parsing, in 1.1 there was s separate ASP.NET parser that was used to provide the SharePoint functionality, and in 2.0 there is a virtual path provider that is used in order to grab the .aspx pages out of the SharePoint SQL database. In both situations, there was a separate module needed to complete the complete page serving, however the context of the object, as you can see, is quite different.