SharePoint provides a few ASP.NET pages which allow you to manage a Portal.  However, business situations arise that require developers to build their own ASP.NET pages.  One situation that comes to mind is an employee directory.  In big organizations you might be tasked with displaying all employees based on search criteria or displaying employees for a particular department.  Once the employees list is displayed, the user might have to get more information on where that particular person is located, the bio information or even the floor map for the employee's office floor.  In this scenario we have the following options:

·         Create a Web Part to display the Employee Directory and then have another ASP.NET application that will have only one page that will display the location of the person.  This ASP.NET page will accept a querystring to get the ID for the employee.  This would be the easiest way accomplish this option, but you would need to maintain a separate application for only one page.

·         The next option might be to develop two web parts.  The first web part has a list of all employees' names.  This web part is a provider web part.  The second web part will contain the location information for the Person.  The second web part will be a consumer web part. The first Web Part provides the second web part employeeID.  The second web part consumes the employeeID.  This option is really good except if the second web part is a really huge display of the floor map and pins where the person is exactly located, the user will have to scroll through the page to find the exact employee location.

·         The last option is building a Web Part similar to option 1 and then building a separate Web Page holding the location information or floor map information.  The Web Part will have a link and will open the floor map information in a separate window.  With this option the ASP.NET web page is also hosted with the SharePoint Portal.  This sounds very simple, but if you try creating ASP.NET pages as they are usually done you will start getting errors because SharePoint does not recognize the plain ASP.NET pages.  So, we will have to do some tweaking to make SharePoint understand that these are SharePoint ASP.NET pages.

The developers might be surprised that the only difference between an ASP.NET page and a SharePoint page is what it is being inherited from.  Normal ASP.NET pages are inherited from System.Web.UI.Page while SharePoint Pages are inherited from Microsoft.SharePoint.WebPartPages.WebPartPage.  Developers may have noticed that while they are developing Web Parts they normally inherit from Microsoft.SharePoint.WebPartPages.WebPart. So, while developing anything specific for SharePoint, you would inherit from objects provided under Microsoft.SharePoint.WebPartPages.  If you look at the inheritance hierarchy for WebPartPage, it is inherited from System.Web.UI.Page (the one that is inherited from for ASP.NET pages).

System.Object

          System.Web.UI.Control

                   System.Web.UI.TemplateControl

                             System.Web.UI.Page

                                      Microsoft.SharePoint.WebPartPages.WebPartPage

So, how do we create a SharePoint Portal Page and include it in our Portal?  The first step is to create the Page.

Steps to create SharePoint Portal Page

·         Normally, I just create a web site on my machine with an appropriate name.

·         Add a reference to the Microsoft.SharePoint Assembly.

·         Add a Web Page.

·         Change the inheritance from System.Web.UI.Page to Microsoft.SharePoint.WebPartPages.WebPartPage.

·         From here on you can just design the page as you want and add functionality to the page.  The design of the page and functionality code is not separate from normal ASP.NET pages.

·         Compile the project.  This will create the assembly file you need to use in SharePoint Portal.

The next major task is how to include it in SharePoint Portal.  The steps required to incorporate the page in your Portal site are the following.

·         Copy the Page to one of the templates folder that will use the Portal Page.

·         Add reference to the Onet.xml file.

·         Copy the assembly file to bin folder of the Portal.

In order to understand where to copy the newly created Web Page, we need to understand the SharePoint Folder structure.

All the portal pages are located under C:\Program Files\Common Files\Microsoft Shared\web server extensions\60.  The site pages or sub areas are being displayed from the template from which they were generated.  For example, the Topics sub area uses the default.aspx page from C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033\SPSTOPIC folders.  Users can create their own templates and store it under C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033\.

An explanation for creating SharePoint Portal Templates is out of the scope of this article.  You can refer to this article which goes into depth of how to create the templates and the folder structure.

In order for SharePoint to recognize the ASP.NET page we just created, it needs to be stored under some template folder.  It would make sense to store the page in a template folder from which the sub area (that uses the Page) is created from.  For example, if a developer is going to create a template called Corporate, then most likely the folder structure will be C:\Program Files\Common Files\Microsoft Shared\web server extensions\60\TEMPLATE\1033\SPSCORPORATE\.  So, the Web Page that is created needs to be stored under this folder.  Please note that you need to copy the ASPX page and nothing else.

Once the page is copied, then we need to let SharePoint know about the presence of the page while creating sub areas.  The article also explains what the Onet.xml file is used for.  In order to make SharePoint aware of the presence of the new Page, we need to make some changes on the Onet.xml file.

Locate the following code under Onet.xml.

Listing 1

<Modules>
  <Module Name="Default" />
  <Module Name="WebPartPopulation" />
</Modules>

Add an entry to the Modules section.  For this example I will call it AmeetArticle.

Listing 2

<Modules>
  <Module Name="Default" />
  <Module Name="WebPartPopulation" />
  <Module Name=" AmeetArticle" />
</Modules>

Now, we also need to reference the pages.  Locate the following code.

Listing 3

<Modules>
  <Module Name="Default" Url="" Path="">
    <File Url="default.aspx" Type="Ghostable">      </File>
  </Module>
  <Module Name="WebPartPopulation" List="113" Url="_catalogs/wp" Path="lists\wplib\dwp" RootWebOnly="TRUE">
    <File Url="MSContentEditor.dwp" Type="GhostableInLibrary" />
    <File Url="MSImage.dwp" Type="GhostableInLibrary" />
    <File Url="MSPageViewer.dwp" Type="GhostableInLibrary" />
  </Module>
</Modules>

In the above section we need to create another module section which references AmeetArticle name declared earlier.

Listing 4

<Modules>
  <Module Name="Default" Url="" Path="">
   <File Url="default.aspx" Type="Ghostable">      </File>
  </Module>
  <Module Name="WebPartPopulation" List="113" Url="_catalogs/wp" Path="lists\wplib\dwp" RootWebOnly="TRUE">
   <File Url="MSContentEditor.dwp" Type="GhostableInLibrary" />
   <File Url="MSImage.dwp" Type="GhostableInLibrary" />
   <File Url="MSPageViewer.dwp" Type="GhostableInLibrary" />
 </Module>
   <Module Name="AmeetArticle" URL="" Path="">
   <File Url="AmeetArticle.aspx" />
   </Module>
</Modules>

If the user has created multiple ASP.NET pages and has created a folder, then the folder path can be provided to the Path attribute under Module.  Once the Path is provided, individual files can be referenced as shown for the AmeetArticle.ASPX page.  With this we can even store the created pages in different templates and reference it through the Onet.xml file.

With the above sections, we have made the SharePoint Portal aware that some external pages are being used in the portal.  But how do we run the functionality behind the pages?  We need to store the assembly file inside the Portal.  This is the easiest part of this whole procedure.  Simply go to the site where your portal is created.  For example, if your portal is called CorporatePortal, then your folder structure might be c:\WebSites\CorporatePortal.  You simply need to copy the assembly file in the bin directory under c:\WebSites\CorporatePortal.  In normal circumstances the bin directory does not exist.  If it does not, you can just create the bin folder and drop the assembly file in it.

If your code needs to reference any sections from the configuration file, you can always edit the Web.Config for your portal and add the sections there.  For example, you might be interested in adding database connection information.  You can add the following section in the Web.Config file.

Listing 5

<appSettings>
  <add key="AmeetArticle" value="Server=AAPW2003SHAREPO;Database=Employee;uid=Employee;pwd=EmployeeTest;" />
</appSettings>

The final step is to do iisreset.

In short, creating SharePoint Portal Pages is as easy as creating normal ASP.NET pages.  This article explained the basics of how to create SharePoint Portal pages, but developers can enhance the functionality by creating their own display pages for different listings or for custom applications. The developer can even use the SharePoint portal controls such as the navigation bar, PageHeader control, BreadCrumbTrail, ToolBar, etc.  Finally, options for customizing the SharePoint Portal are numerous, but finding the best option that suites your needs requires some experimentation.