Understanding ASP.NET Versus SharePoint

If you followed the instructions in Hour 1, “Introducing SharePoint 2010,” you should have SharePoint 2010 installed on your machine. If you take a quick peek into the IIS you see at least two new websites—a website for SharePoint Central Administration and another one for SharePoint Web Services. Open the SharePoint Central Administration by going to Start Menu, All Programs, Microsoft SharePoint 2010 Products, SharePoint 2010 Central Administration. You see a URL like http:// <<machine name>>:<<port no.>> /Default.aspx. Now select SharePoint Central Administration v4 and open the Content View on the right. You do not find any Default.aspx page. So from where exactly is the default.aspx page being fetched? What changes does installing SharePoint Server 2010 make to your environment? To understand all that and more let us first go through a few concepts of ASP.NET.

ASP.NET is the Microsoft Framework that integrates with IIS to help you build highly advanced and robust web applications. A good understanding of how ASP.NET builds on IIS goes a long way toward helping you understand the SharePoint architecture.

You can think of ASP.NET as a request processing engine. It builds on the extensible architecture of the Internet Information Server (IIS). The ASP.NET Framework is implemented as an ISAPI extension named aspnet_isapi.dll. Whenever a user requests an ASP.NET page or a client application makes a call to an ASP.NET Web Service, IIS picks up the request. At the lowest level ASP.NET interfaces with IIS through an ISAPI extension. This request usually is routed to a page with a .aspx extension, but this varies depending on the implementation of the HTTP handler set up to handle the specified extension. In IIS .aspx is mapped through an Application Extension (aka as a script map) that is mapped to the ASP.NET ISAPI DLL—aspnet_isapi.dll. Every request that fires ASP.NET must go through an extension that is registered and points at aspnet_isapi.dll.

IIS starts a worker process if it does not already exist and routes the request to this worker process. This worker process handles the processing of the aspx page. The IIS just acts as a routing mechanism for the requests and response. The worker process corresponds to the Application Pool of the website for which the request was made and runs under the context of the identity defined in the Application Pool configuration. The worker process then routes the request to an appropriate HTTP handler based on the configuration defined in the web.config of the virtual directory or machine.config. Usually this request is processed by the PageHandlerFactory class, which is the default implementation of HTTP handler for aspx pages. Also on the way the request gets processed by various HTTP modules as specified in the configuration. The HTTP handler processes the request and returns the response, which might again be processed on the way by HTTP modules based on the defined configuration. This architecture based on the processing by HTTP handlers has many advantages. It frees the IIS from performing processing directly. In addition there is the concept of a VirtualPathProvider, which abstracts the details of where the files are stored from the ASP.NET runtime. By default in ASP.NET this fetches the file from the file system.

The preceding discussion represents a brief overview of the low level architecture of ASP.NET. ASP.NET is, however, a rich framework that makes web development easy due to multiple reasons, some of which are listed here:

• A rich and vast class library—ASP.NET boasts a rich set of classes that save a lot of effort. Creating an aspx page requires you to simply inherit from the Sytem.Web.UI.Page class. A rich set of controls, such as GridView, ListView, TreeView, and many more, help in building complex user interfaces. Also the programming model behind this is powerful, providing you hooks in the form of events at almost every place in the life cycle of the page.

• User controls and custom controls—In addition to the previous points, ASP.NET provides you the ability to easily create your own reusable controls in the form of custom controls and user controls. The difference between both is that in the case of user controls you get a nice interface in the Integrated Development Environment (IDE) that is the Visual Studio to drag and drop other controls, while in the case of custom controls you need to build the user interface in the code.

• Master pages—Master pages is a powerful concept introduced in ASP.NET 2.0. Master pages enable you to easily achieve a consistent user interface across the application. You define within the master page the elements that are common across all the pages in the application. You also define content placeholders, which are basically sections that the individual pages overwrite to define their individual user interface, within the master page. As you will see SharePoint implements the concept of master pages extensively.

• Extensible architecture—The ASP.NET architecture is extensible, and almost all components can be overridden and replaced by custom components. In later sections you see how SharePoint builds over it.

There is a lot more to ASP.NET, and you will find many good books on it. Let us now see how SharePoint relates to ASP.NET. In a way you can consider SharePoint to be a web application built over ASP.NET. SharePoint transforms an ASP.NET website in IIS into something called a SharePoint web application by adding IIS metabase entries and a lot of web.config entries specific to SharePoint. Using the SPVirtualPathProvider SharePoint fetches the web files from the SQL server. The following lists the changes that installing SharePoint makes to your environment.

• Deploys DLLs related to the SharePoint framework to GAC.

• Creates a special folder called SharePoint root or the 14 Hive at C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14. This is an important folder and contains important files for SharePoint to work.

• Creates and configures a few IIS websites with their configuration updated to turn them into SharePoint web applications. You see the websites for SharePoint Central Administration and SharePoint Web Services. The SharePoint Central Administration site is located at C:inetpubwwwrootwssVirtualDirectories in the folder that in most cases has the same name as the port number you specified during installation. The SharePoint Web Services website is located at C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14Web ServicesRoot.

• Creates the web.config files that contain the additional entries for SharePoint as follows:

• A custom section group called SharePoint is added. This section contains many other entries, the most notable of which is the SafeControls section. You need to add entries for the web parts in this section or you will not be able to run the web part. The following lists the structure of the SharePoint section:

<SharePoint>
<SafeMode />
<WebPartLimits />
<WebPartCache />
<WebPartControls />
<SafeControls />
<PeoplePickerWildcards />
<MergedActions />
<BlobCache />
<RuntimeFilter />
</SharePoint>

• The next section is the Microsoft.SharePoint.Client section, which is newly introduced in SharePoint 2010 and is present for the client object model.

• Next you can see the System.Web section. This section contains entries for custom trust levels called WSS_medium and WSS_minimal. These code access security policies make your SharePoint installation more secure. In addition you see standard ASP.NET concepts such as sitemap providers and WebParts. You also find that the httpModules element is empty.

• The System.WebServer element is a new section with IIS 7. In this element you see the various httpModules configured. This is because SharePoint 2010 works in the integrated pipeline mode. SharePoint removes a number of out of the box HTTP modules. Some of these are the anonymous identification, file authorization, ASP.NET profiles, webDav module, and ASP.NET session module. This is something you need to keep in mind when developing for SharePoint as many of these things applicable in ASP.NET are not applicable in SharePoint.

• Next is the System.ServiceModel section, which enables ASP.NET compatibility for WCF services. You see more about this in upcoming hours.

• Next you have a huge runtime section that specifies many assemblyBinding elements. These elements redirect calls of older versions of SharePoint DLLs to newer versions of DLLs transparently without the calling programs ever knowing about it. Thus if you had a DLL compiled to target SharePoint version 12 (SharePoint 2007), that would automatically be routed to SharePoint 14 (SharePoint 2010).