SharePoint and ASP.NET Integration


Whenever we create a new WSS web application in SharePoint, behind the scene a new IIS Web site gets created. Now to make it SharePoint specific, WSS does the following

 

  • WSS makes few entries into the IIS Metabase. (IIS Metabase stores conifiguration information about it IIS Web Sites and Virtual Directories)
  • Creates virtual directories which maps to 12 hive (installation directory\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\)
    • _controltemplates – where user controls are kept.
    • _layouts – has application pages in it.
    • _vti_bin – dlls and web services repository
    • _wpresources – resource file repository for Web Parts
  • Adds WSS-specific web.config to the root directory of the IIS Web site.
  • Adds wildcard application map to route all incoming to aspnet_isapi.dll. (Right click your iis web site, select home directory, click on Configuration – there we could find the wildcard application map entry.

 

Finally WSS extends the routing architecture of IIS and ASP.NET to properly route all incoming requests through WSS runtime.

 

IIS maps an incoming request to a physical file within root directory of an IIS Web Site or virtual directory. (Virtual directory – an entity defining a child URL space nested within the URL space of its parent IIS Web Site. IIS provides the flexibility of defining the root directory for a virtual directory at any location)

 

IIS supports Internet Server Application Programming Interface (ISAPI) programming model, it allows us to configure an IIS Web Site or virtual directory so that incoming requests trigger the execution of the custom code on the Web Server.

 

ISAPI programming models consists of ISAPI extension and ISAPI filters.

ISAPI extension is a dll that serves as an endpoint for all the incoming requests.

More on ISAPI extension

http://msdn.microsoft.com/en-us/library/ms525172.aspx

 

ISAPI filter-acts as an interceptor. It provides pre as well post processing for each and every incoming request. These extensions are however difficult to develop as they are written in C++.

 

More on ISAPI filters

http://msdn.microsoft.com/en-us/library/ms524610.aspx

 

For better understanding of low level look at ASP.NET architecture

 

http://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp

 

In short, ASP.NET framework is implemented as an ISAPI extension named aspnet_isapi.dll. Whenever IIS sees an incoming request targeting a file with extension like .aspx,.ascx,.asmx, based on the application map defined, it forwards the request to aspnet_isapi.dll, which effectively passes control over to ASP.NET framework.

 

ASP.NET framework compiles an .aspx page to .dll. It parses the .aspx file to generate a C# file that inherits from Page class. Once the ASP.NET page parser builds the source c# file for an .aspx page, it than compile it into a dll. This occurs only the first time when the page is requested; afterwards the same dll is used for all the subsequent requests that target the same page.

 

Now comes into picture HTTP request pipeline exposed by ASP.NET framework. It provides the developer with a degree of control comparable with ISAPI programming model. Http Request Pipeline contains HttpHandler, HttpApplication nad HttpModule components.

 

Once a request comes into the AppDomain managed by the ASP.NET runtime, ASP.NET uses the HttpWorkerRequest class to store the request information. Following that, the runtime wraps the request’s information in a class named HttpContext. The HttpContext class includes all the information you’d ever want to know about a request, including references to the current request’s HttpRequest and HttpResponse objects. The runtime produces an instance of HttpApplication (if one is not already available) and then fires a number of application-wide events (such as BeginRequest and AuthenticateRequest). These events are also pumped through any HttpModules attached to the pipeline. Finally, ASP.NET figures out what kind of handler is required to handle the request, creates one, and asks the handler to process the request. After the handler deals with the request, ASP.NET fires a number of post-processing events (like EndRequest) through the HttpApplication object and the HttpModules.

 

 

HttpApplication – During the lifetime of a Web application, the HttpApplication objects serve as places to hold application-wide data and handle application-side events.

HttpModules – While the Application object is suitable for handling application-wide events and data on a small scale, sometimes application-wide tasks need a little heavier machinery. HttpModules serve that purpose.ASP.NET includes a number of predefined HttpModules. For example, session state, authentication, and authorization are handled via HttpModules.

HttpHandlers –The last stop a request makes in the pipeline is an HttpHandler. Any class implementing the interface IHttpHandler qualifies as a handler. When a request finally reaches the end of the pipeline, ASP.NET consults the configuration file to see if the particular file extension is mapped to an HttpHandler. If it is, the ASP.NET loads the handler and calls the handler’s IHttpHandler.ProcessRequest method to execute the request.

ASP.NET includes several HTTPHandlers already, including System.Web.UI.Page and System.Web.Services.WebService

http://www.brainbell.com/tutorials/ASP/The_ASP.NET_Pipeline.html

WSS uses the above ASP.NET technique to extend the HTTP Request Pipeline.

Configures each web application with custom HttpApplication object using SPHttpApplication class. This class is within Microsoft.SharePoint.dll. It creates a custom global.asax file at the root of Web Application that inherits from SPHttpApplication.

<%@ Assembly Name=”Microsoft.SharePoint”%><%@ Application Language=”C#” Inherits=”Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication” %>

It also makes use of custom HttpHandler and HttpModule as well.

We could find their entries in web.config of the web applciation

  <httpHandlers>

      <remove verb=GET,HEAD,POST path=* />

      <add verb=GET,HEAD,POST path=* type=Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c />

      <add verb=OPTIONS,PROPFIND,PUT,LOCK,UNLOCK,MOVE,COPY,GETLIB,PROPPATCH,MKCOL,DELETE,(GETSOURCE),(HEADSOURCE),(POSTSOURCE) path=* type=Microsoft.SharePoint.ApplicationRuntime.SPHttpHandler, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c />

// other handlers

    </httpHandlers>

<httpModules>

      <clear />

      <add name=SPRequest type=Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c />

// other http modules

    </httpModules>

 

 

 

And finally it makes use of SPVirtualPathProvider, which abstracts the details of where page files are stored away from the ASP.NET runtime, using which the pages are served from content database. Once the content are retrieved by Virtual path provider it is passed to asp.net runtime for parsing. SPRequestModule component contains code to register SPVirutalPathProvider class with ASP.NET framework. SPVirutalPathProvider class works toghether with SPPageParserFilter to supply processing instructions to ASP.NET page parser whether to compile the aspx page to dll or process it in no compile mode.

More on virual path provider

http://weblogs.asp.net/scottgu/archive/2005/11/27/431650.aspx 

Bye..

Understanding Site Collection in SharePoint


Site Collection as we know acts as a container for sites, every WSS site is created inside the scope of the site collection. A site collection would have a top site and could have multiple child or sub sites as well.


Now the question could be that why we require such a container for sites?


One reason is administration.

A user assigned as a site collection administrator has full rights on the existing site as well as any other sites that would be created in the same site collection.

For e.g. in a large organization with multiple departments, we could create different site collections for different departments and could assign administrative rights to someone belonging to that department. Now those users with administrative rights would create additional sites, lists, libraries etc.


Second is authorization.

Security groups, users and their authorization rights are defined independently for each

Site collection.

For e.g. in the above scenario we would be having separate users in separate departments. Each department would be having it’s own site collection and set of groups and users.


Third is Back and Restore

A site collection could easily be backed up and restored either on the same location or inside a different farm as well.

Stsadm –o backup –url http://<server name>:<port> -filename <path\name to be used for the backup file>

Stsadm –o restore –url http://<server>:<port> -filename <path\name of the backup file>

This is how it could be moved from development to staging to production server.


Fourth could be related to site elements (features)

We could have different site elements like web parts, custom menus, site column, content type etc scoped at site collection level which than would be easily available to all the sites within it. And secondly it is easy to write a query that spans entire site collection using SPSiteDataQuery.

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsitedataquery.aspx


Bye..

Understanding IIS Web Site and SharePoint Web Application


SharePoint Web Application could be defined as an IIS Web Site specifically configured to run WSS sites.

 

So the question arises what is an IIS Web Site?

 

IIS Web Site could be defined as an entry point in the IIS Web Server infrastructure.

 

Default web site created listens for incoming HTTP requests on port 80. We could create additional web sites as well, having different port numbers or IP addresses. Every IIS Web site could be configured independently. For e.g. we could have Default Web Site allowing anonymous access and a second IIS Web site that uses integrated authentication.

 

Creating IIS Web Site

http://msdn.microsoft.com/en-us/library/tcywfea7(VS.80).aspx

 

Creating a Web site by using IIS Manager does not create content, but merely creates a directory structure and configuration files from which to publish the content. To publish the Web content, we can place content in the default home directory, or we can create a different home directory or virtual directory and place content there.

 

Creating or extending WSS Web application

http://technet.microsoft.com/en-us/library/cc287954.aspx

 

 

Using Central Administration application we could easily create web site which would be automatically configured to be a WSS Web Application. A new content database gets created for each newly created web application. Normally we would be having one content database per web application. However it is possible to distribute sites within a web application across multiple content databases.

 

Understanding Content databases

http://www.sharepointblogs.com/ethan/archive/2007/09/16/inspecting-the-sharepoint-content-database.aspx

 

http://blogs.msdn.com/sharepoint/archive/2006/08/03/sharepoint-content-database-restrictions-there-are-none.aspx

 

 

Creating multiple content database in a web application

 

http://trycatch.be/blogs/tom/archive/2007/06/21/multiple-databases-for-1-web-application.aspx

 

http://manish-sharepoint.blogspot.com/2009/01/creating-sitecollection-in-new-content.html

 

 

So what happens when a IIS Web Site is transformed to a WSS Web Application?

 

  • WSS makes few entries into the IIS Metabase.
  • Creates virtual directories which maps to 12 hive (installation directory\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\)
    • _controltemplates – where user controls are kept.
    • _layouts – has application pages in it.
    • _vti_bin – dlls and web services repository
    • _wpresources – resource file repository for Web Parts
  • Adds WSS-specific web.config to the root directory of the IIS Web site.
  • Extends routing architecture of IIS and ASP.NET to properly route all incoming requests through WSS runtime.

 

A single web application could have multiple site collection within it and each site collection has a top level site and could have multiple sub sites in it. A WSS site collection acts as a container of WSS Sites.

 

 

Bye ..

 

Differences between Windows SharePoint Services (WSS) and Microsoft Office SharePoint Server 2007 (MOSS)


WSS is included as a part of the Windows Server 2003 whereas MOSS is a separate product.

 

WSS doesn’t have its own licensing model, it is controlled through Windows Server licenses whereas MOSS has it own licensing model that includes both Server-Side as well as client accesses licenses.

 

WSS provides the underlying platform on which MOSS is built on. MOSS includes all the features of WSS and adds its own set of components as services.

 

Additional features that are part of MOSS includes

 

Collaboration

Social networking web parts – Colleague Web Part, Colleague Tracking Web Part, In Common Web Part etc.

 

Enterprise portal

MySite, RSS, Site Directory, User Profile, Audience Targeting,

 

Enterprise search

Enterprise content sources Files shares, Web sites, SharePoint sites, Exchange Public Folders, and Lotus Notes databases, more relevant results, people search, business data search.

Enterprise content management, Forms-driven business processes, Business intelligence.

For complete listings

http://office.microsoft.com/en-us/products/FX101758691033.aspx

 

 

Bye..

Understanding Custom List Definitions in SharePoint.


For creating Custom List Definitions through Feature as a Provisioning Component, we need to create our Feature.xml file that would be pointing to element.xml having our List Definition.

The feature file would be something like this

<?xml version=1.0 encoding=utf-8?>

<Feature Id=00BFEA71-DE22-43B2-A848-C05509900111

    Title=My Custom List Feature

    Description=This is a custom list feature

    Version=1.0.0.0

    Scope=Web

    Hidden=TRUE

    DefaultResourceFile=core

    xmlns=http://schemas.microsoft.com/sharepoint/>

                <ElementManifests>

                                <ElementManifest Location=elements.xml />

                </ElementManifests>

</Feature>

The elements.xml would contain the following information

<?xml version=1.0 encoding=utf-8?>

<Elements xmlns=http://schemas.microsoft.com/sharepoint/>

    <ListTemplate

        Name=CustomList

        Type=10001

        BaseType=0       

        Sequence=2000

        DisplayName=My Custom List

        Description=Creating a custom list/>

</Elements>

 

Element manifest contains ListTemplate element.

Name – Name of the List. One important thing about Name attribute is that there must be a directory with the same name as value of this attribute within the feature directory which would contain schema.xml. All the information for the list would be defined in the schema.xml.

Type – List Type Identifier, for custom list types the value should be more that 10000.

BastType– Value 0 indicates that this list type is for standard list. ( 1- Document library, 3-discussion forums, 5- issue lists)

Sequence– It defines where the link would appear for the list type on the Create Page.

So we would have a folder for feature say My Custom List, this folder feature would have feature.xml,elements.xml and one more folder with name CustomList ( same as Name attribute value at elements.xml) . The CustomList folder contains schema.xml.

Schema.xml would be defining the content types, fields within the content types, views and forms for the list.

This is the basic structure of Schema.xml

<?xml version=1.0 encoding=utf-8?>

<List Title=My Custom List Url=Lists/CustomList BaseType=0>

                <MetaData>

                                <ContentTypes></ContentTypes>

                                <Fields></Fields>

                                <Views></Views>

<Forms></Forms>

                </MetaData>

</List>

In content types, we could add reference to standard as well as custom content types.

Fields- Here we need to include all fields for our referenced content type.

Views- Defining different views for the list.

Forms – We could associate our custom New, Edit or Display form. If not specified than default forms would be used.

Bye…

SharePoint Mobile View


To access the mobile view of our SharePoint sites, we just need to do the following,

just append to the url _layouts/mobile

from

http://servername:port

to

http://servername:port/_layouts/mobile

That’s it..