The Power of "Calcualted Column" in SharePoint

By adding a calculated column to a list or library, you can create a formula that includes data from other columns and performs functions to calculate dates and times, to perform mathematical equations, or to manipulate text. For example, on a tasks list, you can use a column to calculate the number of days it takes to complete each task, based on the Start Date and Date Completed columns.
(Excerpt from the Microsoft Web site)

The best part is using [Today] & [Me] column in a calculated column by this trick :

A List Item's age : link
Days Left/Day in current Year(Birthday) link

In a note on Microsoft website, Please ensure this when using a site column of calculated type :
"The formula in a calculated site column can reference only other site columns that are in the same list or library. Therefore, when you add the calculated site column to a list or library, you must also add the site column that is referenced in the formula."

The big BUT may come when you try to use calculated column in CAML query : Simply change the field type from "Calculated" to "Text" or "Number" or by choice
This solution works but only for a day, as Today's value is static.
Creating a simple window service which creates and deletes a Column with name Today, does the trick. You can also create a SharePoint Timer Job for the same. Though it's a pain initially, bur it works. 
Let me know if you have any difficulty in creating such a solution

What's a Web Part ? How many types of web parts are there in MOSS 2007 ?

Web Parts as defined by MSDN are an integrated set of controls for creating Web sites that enable end-users to modify the content, appearance, and behavior of Web pages in a browser.
In Windows SharePoint Services 3.0 Web Parts ultimately derive from the ASP.WebPart (System.Web.UI.WebControls.WebParts) base class; however, Windows SharePoint Services 3.0 also has a Web Part base class (Microsoft.SharePoint.WebPartPages.WebPart) derived from the ASP.WebPart class. If you are developing Web Parts you can elect to derive from either the Asp.WebPart or WSS.WebPart; however you should carefully consider your approach before developing custom Web Parts for use with Windows SharePoint Services 3.0. To help define the differences, we'll examine each class and their respective pros and cons.

ASP.NET Web Parts
When deriving from the ASP.WebPart your Web Part derives directly from the ASP.WebPart class which does not have a dependency on Windows SharePoint Services 3.0 code so it can be used in both ASP.NET Web sites or a Windows SharePoint Services 3.0 site collection/Web. To ensure the Web Part customization is sustainable you should consider using the ASP.WebParts. ASP.WebParts are exportable using the .webpart extension, can be displayed in SPD using attribute markup and are persisted to the Windows SharePoint Services store in binary Web Part format.
Hybrid (ASP.NET 2.0 + Windows SharePoint Services Web Parts)
Hybrid Web Parts typically derive from the Wss.WebPart base class; however, adhere to the design guidelines for ASP.WebParts though the dependency on WSS.WebPart implies its use strictly in a Windows SharePoint Services 3.0 site collection/Web. Hybrid Web Parts should be considered only where features provided in the WSS.WebParts class are required, for example, client-side connections. Hybrid Web Parts can also be used in version to version upgrades where the existing legacy hybrid Web Part cannot be retired in favor of a ASP.WebPart. Hybrid Web Parts are exportable using the .webpart extension, can be displayed in SPD using attribute markup and are persisted to the Windows SharePoint Services store in binary Web Part format.
Windows SharePoint Services Web Parts
WSS Web Parts derive from the WSS.Web Part base class and meet the guidelines as provided by the Windows SharePoint Services 2.0 Web Part design guidelines. The WSS.WebPart class is obsolete and is retained solely for backwards compatibility. Wss.WebParts are exportable using the .dwp extension, can be displayed in SPD using XML Markup and are persisted to the WSS store in a compressed XML format.
The bottom line is, if you are considering developing custom Web Parts you should consider deriving from the System.Web.UI.WebControls.WebParts.WebPart class and referencing the MSDN guidance on developing ASP.NET Web Parts to ensure the Web Parts to maximize interoperability and sustainability.

WebParts: What's a Hybrid Webpart?

Besides ASP.Net 2.0 and SharePoint 2003 legacy web parts, there is a third floavour of web parts "HYBRID Web parts". Hybrid web parts just like sharepoint legacy web parts, inherit from Microsoft.SharePoint.WebPartPages.WebPart. Hybrid web parts use ASP.Net 2.0 web parts use ASP.Net 2.0 web part development techniques and capabilities combined with SharePoint Capabilities.

There are a couple of things u can do to make a web part HYBRID.

1). Use IPersonalizable interface. This interface is new in .Net 2.o and definies the capabilities for the extraction of personalization state.
2). Use the [ Personalizable ] attribute, which enables a particular property on a web part for personalization.
3). Omit the use of XML serialization attributes.

Drawbacks associated with creating hybrid web parts. Things we can do in a normal sharepoint web part but cannot do in Hybrid Webparts.

a). Hybrid web parts cannnot return tool parts via the GetToolParts() method. Instead, you will need to use controls that inherit from the EditorPart Class via the CreateEditorPart() Method.
b). Properties within a hybrid webpart that are serializable will not be persisted unless you define a type converter for them.

Some sharepoint capabilities can be leveraged with in hybrid web parts. These capabilities are considered advantages of hybrid web parts :

i). You can use the SharePoint 2003 web part caching framework to store items per user or per web part in memory or SQL server.
ii). You can use the sharepoint 2003 web part connection interfaces. you might want to use these interfaces when you want to create web parts that support cross page connections or client side communication.
iii). You can use the asynchronous features of web parts.

Although you will not see hybrid web parts used often but it is good to know they exist. In MOSS 2007 we donot recommend you to create hybrid webparts any more.

Book reffered for article : Pro Sharepoint 2007 Development Techniques By Margriet Bruggeman

SPSiteDataQuery & CrossListQueryInfo

I was about to write an article to explain SPSiteDataQuery & CrossListQueryInfo,When I came across this well written article.
Here is the snippet

SPSiteDataQuery :
    string lists = "";
    string viewFields = "";
    string webs = "";
    SPSiteDataQuery siteQuery = new SPSiteDataQuery();
    siteQuery.Lists = lists;
    siteQuery.ViewFields = viewFields;
    siteQuery.Webs = webs;
    results = SPContext.Current.Web.GetSiteData(siteQuery);

This query returns the title of all items in Issue lists in all sites in the current site collection.If you are running Microsoft Office SharePoint Servers, you can also use the CrossListQueryInfo object to query for content. The advantage is that SharePoint has a caching mechanism for the queries that you run. By using CrossListQueryInfo, your webpart will use this caching mechanism. And you can also make use of audience targeting.


    string lists = "";
    string viewFields = "";
    string webs = "";
    CrossListQueryInfo query = new CrossListQueryInfo();
    query.RowLimit = 100;
    query.WebUrl = SPContext.Current.Site.ServerRelativeUrl;
    query.Lists = lists;
    query.Webs = webs;
    query.Query = "";
    query.ViewFields = viewFields;
    CrossListQueryCache cache = new CrossListQueryCache(query);
    results = cache.GetSiteData(SPContext.Current.Site);

Click here for complete article.

Following is a description for the available types (available in the WSS SDK)


Value Description

100 Generic list

101 Document library

102 Survey

103 Links list

104 Announcements list

105 Contacts list

106 Events list

107 Tasks list

108 Discussion board

109 Picture library

110 Data sources

111 Site template gallery

113 Web Part gallery

114 List template gallery

115 XML Form library

120 Custom grid for a list

200 Meeting Series list

201 Meeting Agenda list

202 Meeting Attendees list

204 Meeting Decisions list

207 Meeting Objectives list

210 Meeting text box

211 Meeting Things To Bring list

212 Meeting Workspace Pages list

300 Portal Sites list.

1100 Issue tracking

2002 Personal document library

2003 Private document library


0 — Custom List

1 — Document Library

2 — Not used

3 — Discussion Forum

4 — Surveys

5 — Issues List

so, if you are developing custom picture library set Type="109" and BaseType="1" (because picture library mainly based on document library)

Custom Default Masterpage for all Site Definitions in WSS 3.0

How to set a custom default masterpage for all site definitions in WSS3 ?
How can we deploy the new custom masterpage for all site definitions ?

1). Put the new masterpage in the following directory: "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\GLOBAL"

2). Go to "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\GLOBAL\XML" and open the ONET.XML.

3). At the bottom of the page add a new masterpage entry so it will look something like this:

'<'Module Name="DefaultMasterPage" List="116" Url="_catalogs/masterpage" RootWebOnly="FALSE"'>'
'<'File Url="[any name].master" Type="GhostableInLibrary" IgnoreIfAlreadyExists="TRUE" /'>'
'<'File Url="default.master" Type="GhostableInLibrary" IgnoreIfAlreadyExists="TRUE" /'>'

This code will automatically put your custom masterpage into the masterpage gallery when a new site is created.

  • Change the default masterpage to the new one. Look for the following line: and change it to your new masterpage.
  • Hit save, and do an IISRESET.

Now create a new site and the new masterpage is set automatically.

Beware that when you create a masterpage with SharePoint designer you cannot just export the masterpage to the filesystem, because it will mess up your masterpage code. You can better copy the masterpage code to notepad, and save it as your masterpage on the filesystem.

Overview of SharePoint Portal Server Object Model

This article provides a general overview of the SharePoint Portal Server object model. The Microsoft Office SharePoint Portal Server object model encompasses a number of namespaces—about 50 in total—that provide a way to manipulate SharePoint Portal Server configuration and information.

The object model is so large, it cannot possibly be fully covered here; however, this article will discuss the most important and frequently used namespaces, classes, and methods. It will provide an overview of these components and provide samples useful for developers.

Out of the approximately 50 namespaces provided in the SharePoint Portal Server object model, only 16 of them are supported. The remaining namespaces are reserved for Microsoft’s internal use.

The Microsoft.SharePoint.Portal Namespace
All code and references in the SharePoint Portal Server object model stem from the Microsoft.SharePoint.Portal namespace. The definition for this namespace is found in Microsoft.SharePoint.Portal.dll. When creating projects, you will need to reference this file. The Microsoft.SharePoint.Portal.dll file contains the code for most namespaces under Microsoft.SharePoint.Portal. The following namespaces are not included in this assembly:


Included in the Microsoft.SharePoint.Portal namespace are two very important classesPortalApplication and PortalContext. These two classes are the basis for any code written against the SharePoint Portal Server object model.
The PortalContext object is extremely important because it is the entry point for using almost every other object in the SharePoint Portal Server object model.
The PortalApplication class provides functions that can get a PortalContext object.

The following code shows how to get a PortalContext object from an HTTP Context object:
PortalContext context = PortalApplication.GetContext(Context);


The Microsoft.SharePoint.Portal.Topology namespace provides functions for interacting with a SharePoint Portal server farm. Using this namespace, you can add servers to a farm, change the configuration database, get a listing of servers in the farm, and in fact build a farm completely through the functions in this namespace. You can also use objects in this namespace to get Microsoft Windows SharePoint Services objects in the Microsoft.SharePoint.Administration namespace. For example, you can get a collection of VirtualServer objects that the farm uses and then perform Windows SharePoint Services operations on those VirtualServer objects to add a Web Part to all virtual servers in the farm.

Another crucial function that the Microsoft.SharePoint.Portal.Topology namespace provides is allowing you to get a PortalContext object from a Console application or a Windows Forms application. For this, you would use the TopologyManager object to get a specific PortalSite object for the portal site you want to connect to. The following code snippet demonstrates how to get a PortalContext object from a console or Windows Forms application:

TopologyManager topology = new TopologyManager();
PortalSite portal = topology.PortalSites[new Uri(http://test-server)];
PortalContext context = PortalApplication.GetContext(portal);

It is important to remember that the URI you pass as an indexer in the preceding sample must be the default portal site URL. For example, if you have a portal site available at http://test-server and the URL also points to that site, you can only use http://test-server in the code example. Otherwise, the code will throw an exception since the object model gets the reference of the site from the database, and only the default URL is stored.

The Microsoft.SharePoint.Portal.UserProfiles namespace is one of the most useful namespaces for Windows Forms and Console applications. It is often used to perform administrative functions. For example, if you do not have Active Directory to import user profiles from, you could use the namespace to import user profiles from any other directory service. You could also pre-create My Sites, otherwise known as Personal Sites, for all users with this namespace so that the server does not have a load spike in production when a user clicks to create a My Site. Creating My Sites are expensive in terms of processor time because they are the same as creating a new Site collection, so it can be beneficial to expend the processor time to create these before the servers go into production.

With this namespace, you can also work with a user’s profile and My Site. You can add properties to the profile, add links to all users’ My Sites, or create reports to see how many users are using their My Site. This namespace provides excellent functionality for administrative functions. This namespace provides administrative functions.

The following code snippet demonstrates how to import user profiles from a text file. It assumes that each property is delimited by a colon (:) character.

public static void Import (string filename)
TopologyManager topology = new TopologyManager();
PortalSite portal = topology.PortalSites[new Uri(http://test-server/)];
PortalContext context = PortalApplication.GetContext(portal);
//initialize user profile config manager object
UserProfileManager profileManager = new UserProfileManager(context);
//Open Text File containing user information
System.IO.FileInfo file = new FileInfo(filename);
System.IO.StreamReader fs = file.OpenText();
string read;
while ((read = fs.ReadLine()) != null)
//parse line
string[] userInfo = read.Split(":".ToCharArray());
//create user profile if it doesn't exist
string userAccount = userInfo[0];
if (!profileManager.UserExists(userAccount))
//Get the userprofile so it can be changed
UserProfile userProfile = profileManager.GetUserProfile(userAccount);
// Set users Preferred name to their first + last name.
userProfile["PreferredName"] = userInfo[2] + " " + userInfo[1];
userProfile["WorkEmail"] = userInfo[0] + "";
The next example demonstrates how to add the corporate Web site URL to every user’s Links Web Part. This Web Part is shown on the users’ My Site. You can use this code to add any links that you deem necessary for all users. The sample code is a function that adds the passed URL and title to the “Corporate” category. With modifications, you could also use the code to add certain links to specific sets of users.

public static void Add(string url, string title, bool IsPublic)
TopologyManager topology = new TopologyManager();
PortalSite portal = topology.PortalSites[new Uri(http://test-server/)];
PortalContext context = PortalApplication.GetContext(portal);
//initialize user profile config manager object
UserProfileManager profileManager = new UserProfileManager(context);
foreach (UserProfile profile in profileManager)
profile.QuickLinks.Add(title, url, "Corporate", IsPublic);
The next example shows how to create My Sites for all users in the profile database in one shot. It is often useful to create sites for all users before the SharePoint farm goes live to save the performance hit of creating the site during peak times.

public static void Create()
//Connect to the portal and get the portal context.
TopologyManager topology = new TopologyManager();
PortalSite portal = topology.PortalSites[new Uri(http://test-server)];
PortalContext context = PortalApplication.GetContext(portal);

//initialize user profile config manager object
UserProfileManager profileManager = new UserProfileManager(context);
foreach (UserProfile profile in profileManager)
Console.Write("Creating a Personal Site for " + profile["PreferredName"] + "..." );
catch (PersonalSiteExistsException)
Console.Write("Site already exists!\n");
{ // Write code to Log or Display Error }
This final example will create a report which displays all users in the profile database and the URL of their My Site. It will display “None” for the URL if the user does not have a My Site. It will also display the total number of users who have already created a My Site. This report could easily be modified to calculate the size of each user’s My Site and the total size of all My Sites, among other useful information.

public static void Report()
int usersWithProfiles = 0, usersWithoutProfiles = 0;
//Connect to the portal and get the portal context.
TopologyManager topology = new TopologyManager();
PortalSite portal = topology.PortalSites[new Uri(http://test-server)];
PortalContext context = PortalApplication.GetContext(portal);
//initialize user profile config manager object
UserProfileManager profileManager = new UserProfileManager(context);
foreach (UserProfile profile in profileManager)
Microsoft.SharePoint.SPSite personalSite = profile.PersonalSite;
if (personalSite == null)
Console.WriteLine(profile["PreferredName"] + " : " + "NONE");
Console.WriteLine(profile["PreferredName"] + " : " + personalSite.Url);
Console.WriteLine("Users with Personal Site: " + usersWithProfiles.ToString());
Console.WriteLine("Users without Personal Sites: " + usersWithoutProfiles.ToString());

The Microsoft.SharePoint.Portal.WebControls namespace provides several base classes for Web Parts and for interacting exclusively with a portal site. You would not use this namespace from a Console or Windows Forms application because it can only be used from Microsoft ASP.NET. The classes in this namespace are incredibly useful because they take a significant amount of work out of developing repeatedly used functions such as a cacheable Web Part.
Description of Classes in the Microsoft.SharePoint.Portal.WebControls
AudiencePicker : This class provides the same graphical audience picker that is used when targeting content to particular audiences.
BaseAreaWebPart : This class is an inheritable base class that acts like an area. It creates a Web Part that is cacheable, increasing its performance. The Web Parts in the default areas inherit from this Web Part.
BreadCrumbTrail : This class provides a hierarchical view of where the user is in relation to other areas. It will show the parent area and subareas.
CategoryNavigationWebPart : This Web Part implements the top horizontal navigation bar for the portal site and the side navigation bar.
CacheableWebPart : This class provides a base class for a Web Part that implements output caching. Output caching is important to achieve high performance for Web Parts that do not change frequently.
CategoryPicker : This class provides a graphical category hierarchy. It is very similar to the Portal Site Map, provided with SharePoint Portal Server, allowing you to see a list of areas.
HtmlMenu : This class implements an HTML menu much like the drop-down menu SharePoint sites use in many lists.
HtmlMenuButton : This class implements the drop-down button that will display an HtmlMenu class when clicked on.
HtmlMenuItem : This class represents a particular item on an HtmlMenu class.
SearchBox : This class implements a text box and the search functionality behind that box. If you want to develop a more advanced search, this class would be the starting point.
SearchResults : This class implements the SharePoint Portal Server Search Results Web Part. If you want to develop a more advanced search results part, this class would be the starting point.
TextEditor : This class implements the rich text editor control used throughout SharePoint sites.


This namespace provides functions for interacting with the search catalogs. You can manage the catalogs by adding or removing content sources, forcing propagation of the catalogs, and forcing a type of crawl (Full, Incremental, and so on) on a specific search catalog. This namespace, however, does not let you work with individual content sources, only full search catalogs, so you cannot crawl a particular content source directly using the functions, only a particular catalog, such as Portal_Content.


The Microsoft.SharePoint.Portal.Search namespace provides only one single class—QueryProvider. With this class, you can call the search service. Although this class does provide the search ability, it is better to use the Search Web service. The Search Web service is more robust and easier to use, plus the code that calls the QueryProvider class can only be run on the local server running SharePoint Portal Server.


This namespace provides classes and functions for manipulating search scopes. With the namespace, you can add, remove, move, update, and list the search scopes on a particular portal site.


This namespace implements the Search Web service, the SPSQueryService class. Using the Search Web service explicitly instead of going through this class is generally easier and allows your code to be run from remote machines.


This namespace contains classes and functions required for accessing the Single Sign-On service provided with SharePoint Portal Server. You can add different applications, set up the credentials systems, and request credentials from this namespace.


This namespace contains classes for managing access to the Single Sign-On credentials.


This namespace contains functions for working with security in the portal sites. It contains the classes for users, roles, and permissions. If you want to use code to create roles or add users to roles, you would use this namespace.


This namespace contains functions for working with SharePoint Portal Server audiences. You can get users in particular audiences, create audiences, and rebuild audiences with this namespace. You can use the functions in this namespace to build a Web Part that tailors its information based on audience membership, giving you more flexibility than just targeting a Web Part.


The Microsoft.SharePoint.Portal.Alerts namespace and its subnamespaces, Microsoft.SharePoint.Portal.Alerts.Types and Microsoft.SharePoint.Portal.Alerts.NotificationTypes, allow you to work with alerts. You can change alerts, remove alerts, add alerts, and enable/disable alerts programmatically.


The Microsoft.SharePoint.Portal .SiteData namespace provides functions for working with areas. It contains the code for creating areas, removing areas, applying certain area templates, and associating keywords with areas. With this namespace, you can also associate audiences with areas and work with area listings. If you want to manipulate areas through code, you would work with this namespace. It is faster and easier to perform the functions exposed here through the SharePoint Portal Server user interface.

Directory Structure In The 12 Hive

The 12 hive is where everything in SharePoint happens and is where all the binaries, configuration, web pages, web controls, help files and other resources reside. As a developer writing your own features for SharePoint, it is vital that you learn where things go and where you should be targeting your resources.
This article however is aimed at an administrator and developer with a basic overview of what you can find where.

Below is a list of core folders in the 12 hive.
\ADMISAPI : The directory contain the web service used used by the SharePoint Central Administration and appears as a virtual directory.
\BIN : The directory contains all the core binary files, utilities that are used by Windows SharePoint Services. Your command line tools such as STSADM.EXE reside in this folder.
\BIN\LCIDD : A directory will be created for each language, which contains language specific binary files.
\CONFIG : This directory contains a set of configuration, binary and resource files used by SharePoint. Some files are the default values which will be copied to web site instances.
\DATA : SharePoint uses this directory structure for the indexing services where content will be indexed.
\HCCab\LCID : This directory has a set of cab files containing manifest and content information used by the SharePoint help sytem.
\Help : The folder contains a compiled html help file (.chm) used by the configuration wizard.
\ISAPI : This directory contains all the standard Web Services for SharePoint and some additional DLL's, resources and configuration files that the web services use. Every web application provisioned in SharePoint will have a virtual directory "_vti/_bin" that points to this directory, thus giving each web application it's own set of web services.
\ISAPI\HELP : This directory contains all the help files used by SharePoint. The folder also contains LCID sub directories for each language installed thus globalising the help system.
\LOGS : This is the directory that you will be visiting frequently while doing development and administration as it contains the log files of what SharePoint did and what errors occurred.
\Resources : This directory contains the core.resx file used for creating language packs for SharePoint. If you are going to be localising your SharePoint sites with different languages and cultures, this is the folder to do it in.
\TEMPLATE : This directory structure contains the core web site functionality in SharePoint, that is the features, templates, configurations, resources of a web site. What is important to note about this directory structure is that the Virtual Path Provider hides and masks this directory structure, thus it appears under each web site, list in a completely different structure. As a SharePoint developer you should completely familiarise yourself with this folder structure.

SharePoint - The 12 Hive

In Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server the actual installation location is:
"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12"

In WSS 3.0, The 12 hive is directory structure where the product is installed into. This folder structure is where all the relevant web pages, features, Site definitions and web services are installed to.
Of note is the TEMPLATE directory, this directory contains all the necessary web page files that have been provisioned by default.

WARNING! You should not add to, modify or delete files in the 12 Hive. To add custom functionality to the 12 Hive (including branding) should be done through SharePoint Designer or provisioning using .wsp files.

Tips :
Create a shortcut to this folder structure on your desktop as it is an important folder structure for you to use.
2). Add a search path by editing your environment variables to: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN

Executables in the 12 Hive

1). HCINSTAL.exe - This appears to be the executable that will install the Help Collection.

2).MSSDMN.exe - This is a process related to populating full text indexes. It brings the text data from the SQL Server table to the full-text index.

3). MSSEARCH.exe - Also related to indexing on SQL Server but can also be used for Exchange.

4).OWSTIMER.exe - This is the program that tracks SharePoint's "to do" list. It is critical for alerts and use logs.

5). PRESCAN.exe - This is a program that analyzes your site to identify issues before you upgrade a site.

6). PSCONFIGUI.exe - I think it's the configuration wizard. Still working on it.

7). SPWRITER.exe - This is the volume shadow copy service (VSS) reference writer.

8). STSADM.exe - This is the admin command line console.

9). WSSADMIN.exe - This is the service that runs the various administrative functions.

10). WSSTRACING.exe - Not sure what this one does. It logs records out to the diagnostic log file.

If you've got better links or explanations, I'd love for you to share them.

Exploring the 12 Hive : TEMPLATE Directory

We will take a look at the structure of the file system in SharePoint 2007 and how the files are used. As a developer you must know about the 12 HIVE folder.

If we look at a standard Microsoft Office SharePoint 2007 installation we can see that a new directory has been created under the following;
C:\Program Files\Microsoft Shared\Common Files\web server extensions
You will now see a 12 directory. This is known as the “12 HIVE” and is the directory that holds the necessary system files that drive SharePoint 2007.

The following directories can be found under the 12 hive;
For the purposes of SharePoint development you will, for the majority of the time, be working with the TEMPLATE directory.

The TEMPLATE DirectoryHere is the structure under the TEMPLATE directory;

1033 - ADMIN - CONTROLTEMPLATES - DocumentTemplates - FEATURES - GLOBAL - IMAGES - LAYOUTS - Pages - SiteTemplates - SQL - THEMES - XML

The TEMPLATE\1033 Directory : There are two directories that you need to know about here. The Workflow directory is where you will find the WSS.ACTIONS file. This file is used by SharePoint Designer 2007’s Workflow Designer. All of the workflows functions available to Designer are defined here. If you create workflow functionality using Visual Studio 2005/2008 and you want the functions to appear within the Workflow Designer, you will need to create a new .ACTIONS file.

The TEMPLATE\1033\STS Directory : The SharePoint Team Services or STS directory has one sub-directory within it. The DOCLIB directory contains several further sub-directories, each of which holds a template for a specific content type. There are templates for the Office applications, Word, Excel, PowerPoint and OneNote. There are also templates for the different types of page that can be created in SharePoint.

The TEMPLATE\1033\XML Directory : A more important directory within 1033 is the XML directory. Within this directory are several XML files.

Note : Changes to any of the file could be overwritten by SharePoint Service Packs.

DEADWEB.XML – This file is used during the site expiration process. Only change this file if you need to change the message that is displayed during the site expiration process.
RGNLSTNG.XML – This file holds the regional settings used by SharePoint 2007. You should not need to change this XML file.
WEBTEMP.XML – This file defines the pointers to the GLOBAL, STS, MPS, CENTRALADMIN, WIKI and BLOG site definitions. You can amend this file to either display or hide site templates during the New Site Creation process (newsbweb.aspx and scsignup.aspx).

WEBTEMPBDR.en-US.XML – This file defines the pointers to the BDR site definition. You can amend this file to either display or hide site templates during the New Site Creation process (newsbweb.aspx and scsignup.aspx).

WEBTEMPOFFILE.XML - This file defines the pointers to the OFFILE site definition. You can amend this file to either display or hide site templates during the New Site Creation process (newsbweb.aspx and scsignup.aspx).
WEBTEMPOSRV.XML - This file defines the pointers to the OSRV site definition. You can amend this file to either display or hide site templates during the New Site Creation process (newsbweb.aspx and scsignup.aspx).
WEBTEMPSPS.XML - This file defines the pointers to the SPS, SPSPERS, SPSMSITE, SPSTOC, SPSTOPICM, SPSNEWS, CMSPUBLISHING, BLANKINTERNET, SPSNHOME, SPSSITES, SPSCOMMU, SPSPORTAL, SRCHCEN, PROFILES, BLANKINTERNETCONTAINER and SPSMSITEHOST site definitions. You can amend this file to either display or hide site templates during the New Site Creation process (newsbweb.aspx and scsignup.aspx).
WEBTEMPSRCH.XML - This file defines the pointers to the SRCHCENTERLITE site definition. You can amend this file to either display or hide site templates during the New Site Creation process (newsbweb.aspx and scsignup.aspx).
It is preferable to clone and existing site definition and associated WEBTEMPxxx.XML file rather than edit an existing one. This will prevent your changes from being overwritten if a Service Pack is applied.
The final directory under 1033 is STS. This directory holds a subdirectory, DOCTEMP which contains further subdirectories that hold the definitions and templates for document types that are associated with document libraries. You will find templates for Microsoft Word, Excel and PowerPoint amongst others. You should not need to amend any of these files.

The TEMPLATE\ADMIN Directory : The files in the ADMIN directory are used by the Central Administration pages. There are three directories within ADMIN; 1033, Content Deployment and SSO. 1033\Policy\Report contains a reporting template and sample data. The Content Deployment directory contains the DeploymentUpload.aspx page. Finally, SSO contains all of the aspx pages for Single Service Sign-On. These files should not be amended.

The TEMPLATE\CONTROLTEMPLATES Directory : The CONTROLTEMPLATES directory is where the ASP.NET 2.0 control template files are held. Control templates are small re-usable files that contain components of a web page. An example is welcome.ascx. The welcome.ascx file defines the dropdown menu that appears under Welcome name on the top navigation section of a SharePoint 2007 page.
These pages are pulled into SharePoint 2007 aspx pages. You can create your own ascx pages.

The TEMPLATE\DocumentTemplates Directory : This directory contains one file, wkpstd.aspx, which is the base master file for Wiki pages.
Tips & Tricks : It is worth noting that although this page can be cloned and modified it will not be used by any Wiki page other than the first page that is created. This is because the wkpstd.aspx page is hard coded and is always used to create further Wiki pages.

The TEMPLATE\FEATURES Directory : The FEATURES directory holds subdirectories for each Feature that is available within SharePoint 2007. Each of these subdirectories will hold at least one file, feature.xml – this file will define the Feature and will have pointers to any other files required by the Feature.

The TEMPLATE\GLOBAL Directory : The GLOBAL directory holds two very important files; default.master and mwsdefault.master.
The default.master file is the master file that all files are based on. If you change this file, the change will be applied to every page that was created using an out-of-the-box site definition.

The mwsdefault.master file is the master file that all Meeting Workspace files are based on. If you change this file, the change will be applied to every Meeting Workspace page that was created using an out-of-the-box site definition.

The GLOBAL\XML directory holds the master ONET.XML file and master view XML files.
You should not need to modify any of the files within the Lists or XML directories at this time.

The TEMPLATE\IMAGES Directory : The IMAGES directory holds all images used within SharePoint 2007.

The TEMPLATE\LAYOUTS Directory : The LAYOUTS directory is another one of those directories that you should pay attention to. If you ever see /_layouts/ in the URL of one of your SharePoint sites, the aspx page will be in this directory. You will also notice the odd .ascx (control template), .js (JavaScript) and .master file within this directory. I am not sure why Microsoft didn’t tidy these files up and put them in more appropriate directories – as you become more familiar with SharePoint you will notice little inconsistencies like this.
In the LAYOUTS directory is application.master, the master file for all of the “admin” type pages, such as upload.aspx. When you begin to look at site customisation and branding you will see that application.master is one of the files that will need to be looked at.
The 1033\IMAGES directory : contains many of the images used in publishing sites, such as the thumbnails for each of the different pages types. There are also icons in this directory.
The 1033\STYLES directory : contains additional cascading style sheet (CSS) files.
The MOBILE directory : contains a series of aspx pages that are optimised for mobile devices.
The STYLES directory : contains one file, corefixup.css – more of an afterthought by Microsoft?

The TEMPLATE\Pages Directory : The Pages directory contains three aspx pages that are pulled in as subpages to other aspx pages.

The TEMPLATE\SiteTemplates Directory : A slightly misleading directory name as the SiteTemplates directory actually contains all of the SharePoint Site Definitions. It is in this directory that you would create any new site templates. There is a sub-directory for each site definition. Each sub-directory will contain at least an XML directory and a default.aspx file. The aspx file is the initial home page that is displayed when a site definition is used in SharePoint. The XML directory : will contain at least an ONET.XML file, which defines the setup of the site definition, such as which Features to load, where the web parts go and what they are, which document library templates to assign.
There will be extra files in some of the directories but they are used to provide the extra functionality that the site definitions require.
When creating new site definitions, you will place your directories here. Please have a look at our blog for creating custom site definitions in more detail.

The TEMPLATE\SQL Directory : The SQL directory contains a series of XML and SQL files. Some of these are used to define SharePoint configuration and content databases. You should not change these files.

The TEMPLATE\THEMES Directory : The THEMES directory contains 22 sub-directories, one for each theme that is available within SharePoint. Each sub-directory contains all of the files required for the theme, including all the images and the cascading style sheets.
You can create your own custom theme and place it within the THEMES directory. Please visit our blog Creating Custom Themes.

The TEMPLATE\XML Directory : The final directory, XML, contains XML and XSD files that are used in configuration of SharePoint. You shouldn’t need to venture in this directory, but if you do, be aware that any file you modify may be overwritten by SharePoint Service Packs.

alerttemplates.xml : Used to change the look and feel of Alert Notification emails for each list, web or custom types in your SharePoint Environment. You can set custom branding based on your to your email alerts.

BASE.XML : defines base types for lists that apply globally to all the SharePoint Web sites.

DOCICON.XML : This file is used for mapping file types to particular icons. To add the new icon to the file type follow below steps.
1). To add a .pdf (Adobe PDF) file name extension, add the following line to the ByExtension section in this file—

'<' Mapping Key="pdf" Value="pdf16.gif"/ '>'.
2). Add the file pdf16.gif (use Google Image Search to get this image) to the Program Files\Common Files\Microsoft Shared\web server extensions\12\Template\Images.

FLDTYPES.XML : Used to define how various SharePoint field types are rendered.

fldtypes_hold.xml : Used to define the hold status pertaining to entities realted to Records Management Policy. Note: This file is meant for internal use and it is recommended not alter the contents.

fldtypes_publishing.xml : Used to define the publishing field types like HTML, Links, Summary Links etc. In case of creating a new custom publishing field type, say Address (with validation) then a new entry related to this filed type has to be added to this file.All other xml files with prefix fldtypes are cutom built field types. Yet another notable field type is Business Data field. This field type is defined in fldtypes_spsbizdata.xml.

htmltransinfo.xml : Used to define the how to open various documents stored in the sharepoint server. The mapping entry for a particular document in this XML file will tell SharePoint server to open the document in a particular client application. If the document conversion mapping is not found in this file, SharePoint will prompt the user to download the document.

SharePoint is flexible enough for you to create custom properties by creating custom XML files in this directory.

This is a good start for you to go off exploring further in TEMPLATES Directory.

Handling Error "Centrally" in a SharePoint Application

It will be nice if SharePoint displays all types of error message on a custom screen. And certainly it's possible. This sample shows how to handle errors centrally in a SharePoint.

In MOSS, you most likely have seen this screen:
"An unexpected error has occurred." is something that you probably don't want in your application. We want to have customized error page. In ASP.NET application you normally put Application_Error into you global.asax file. However in SharePoint that place has been taken by the product itself :-) So for customized approach we can take HttpModule approach.

So let's create our custom exception handler http module. Here's the code for that:

From the code we'll attach my code to the Error event and in my event we'll do some basic stuff and then transfer it to my MyCustomErrorPage.aspx. I used Server.Transfer just because I want user to stay at the same url where exception happened. If the url stays the same the user can actually press F5 and retry the operation. Of course it can be bad thing too and you may want to redirect to another page to avoid creating the same exception all over again. You decide what you want :-) So do some testing and then decide what's good for you.
Important thing to notice. You need to put your IHttpModule before SharePoint specific modules in your web.config or otherwise your error routines may not work as you would expect. Here's example from that:

For Reference :

U2U Caml Query Builder : new version released

Karine has released a new version of CAML builder with
  • Code snippet generation
  • DateTime enhancements
  • Query options for SPQuery
  • Enhancements for Calendar lists

You can read all about these in her latest blog posting.1

Microsoft Sharepoint “Tips of the Day”

Microsoft has made available a list of tips and how-tos for SharePoint, Sharepoint Designer, and InfoPath and of course, all the other Office products as well. Best of all, they are available by RSS feed, so you can have them delivered right to your mailbox.

You can choose which feeds you would like to subscribe to. Some of the most recent posts have included:

· How to Design an InfoPath Form based on XML Schema
· Create a workflow initiation form
· How to use variables in workflows
· How to export Excel data to a Sharepoint site
· Connect a Query String Filter to another Web Part

For a complete list of feeds and to choose what tips you would like to subscribe to, visit