Monday, September 29, 2008

SharePoint : WSS 3.0/MOSS feature list

Windows SharePoint Services v3 Features:

33 Features in WSS v3
  • AdminLinks
  • AnnouncementsList
  • BasicWebParts
  • ContactsList
  • ContentLightup
  • ContentTypeSettings
  • ctypes
  • CustomList
  • DataSourceLibrary
  • DiscussionsList
  • SiteSettings
  • SPSearchFeature
  • SurveysList
  • TasksList
  • TeamCollab
  • UpgradeLinks
  • DocumentLibrary
  • EventsList
  • fields
  • GanttTasksList
  • GridList
  • IssuesList
  • IssueTrackingWorkflow
  • LinksList
  • MobilityRedirect
  • NoCodeWorkflowLibrary
  • PictureLibrary
  • WebPageLibrary
  • WikiWelcome
  • WorkflowHistoryList
  • WorkflowProcessList
  • XmlFormLibrary

Microsoft Office SharePoint Services 2007 Features:

107 Features Added in MOSS 2007*
  • AddDashboard
  • Analytics
  • AnalyticsLinks
  • BaseSite
  • BaseSiteStapling
  • BaseWeb
  • BaseWebApplication
  • BDCAdminUILinks
  • BDR
  • BizAppsCTypes
  • BizAppsFields
  • BizAppsListTemplates
  • BizAppsSiteTemplates
  • BulkWorkflow
  • BulkWorkflowTimerJob
  • DataConnectionLibrary
  • DataConnectionLibraryStapling
  • DeploymentLinks
  • DMContentTypeSettings
  • EawfSite
  • EawfWeb
  • EnhancedHtmlEditing
  • ExcelServer
  • ExcelServerSite
  • ExcelServerWebApplication
  • ExpirationWorkflow
  • FeaturePushdown
  • GlobalWebParts
  • GradualUpgrade
  • Hold
  • ipfsAdminLinks
  • IPFSAdminWeb
  • IPFSDocumentConversion
  • IPFSSiteFeatures
  • IPFSWebFeatures
  • LegacyDocumentLibrary
  • PublishingLayouts
  • PublishingPrerequisites
  • PublishingResources
  • PublishingSite
  • PublishingStapling
  • PublishingWeb
  • RecordsManagement
  • RedirectPageContentTypeBinding
  • RelatedLinksScopeSettingsLink
  • ReportCenterCreation
  • ReportCenterSampleData
  • Reporting
  • ReportListTemplate
  • ReviewWorkflows
  • SearchAndProcess
  • SearchWebParts
  • SharedServices
  • SignaturesWorkflow
  • SitesList
  • SkuUpgradeLinks
  • SlideLibrary
  • SlideLibraryActivation
  • ListTargeting
  • LocalSiteDirectoryControl
  • LocalSiteDirectoryMetaData
  • LocalSiteDirectorySettingsLink
  • MasterSiteDirectoryControl
  • MigrationLinks
  • MySite
  • MySiteBlog
  • MySiteCleanup
  • MySiteHost
  • MySiteLayouts
  • MySiteNavigation
  • MySiteQuickLaunch
  • Navigation
  • NavigationProperties
  • OffWFCommon
  • OSearchBasicFeature
  • OSearchCentralAdminLinks
  • OSearchEnhancedFeature
  • OSearchPortalAdminLinks
  • OSearchSRPAdminLinks
  • OsrvLinks
  • OsrvTasks
  • OssNavigation
  • OSSSearchSearchCenterUrlFeature
  • OSSSearchSearchCenterUrlSiteFeature
  • PageConverters
  • PortalLayouts
  • PremiumRootSite
  • PremiumRootSiteStapling
  • PremiumSite
  • PremiumSiteStapling
  • PremiumWeb
  • PremiumWebApplication
  • ProfileSynch
  • Publishing
  • SpellChecking
  • SPSDisco
  • SpsSsoLinks
  • SRPProfileAdmin
  • StapledWorkflows
  • TranslationWorkflow
  • TransMgmtFunc
  • TransMgmtLib
  • UpgradeOnlyFile
  • UserMigrator
  • ViewFormPagesLockDown
  • WebPartAdderGroups
Please refer Andrew Connell's blog for detailed information [Reference:]

Tuesday, September 23, 2008

SharePoint: Deploying WebPart/Feature as SharePoint Solution Package (.wsp file) - Part 4

Link to Part 1 : Creating Skeleton.
Link to Part 2 : Creating Features/Webparts
Link to Part 3 : Creating .ddf and Manifest.xml
Link to Part 4 : Using STSADM and Centeral Admin to add and deploy solution (current post)

Upon successfull completion of build, you will se two additional folder, in bin\debug directory. Namely:
  • cab: contains cab file
  • wsp: contains wsp file
reason for creating cab file is:
  • to verify is all referenced file are included in the solution
  • to verify file heirarchy

Upon successful verification of solution, we move forward on how to deploy solution in SharePoint 2007.

Deploying the solution file to SharePoint is a two-step process: First, register the solution in the database. Registration is accomplished from the STSADM command-line utility. To add the test.wsp file, run the utility like this:

STSADM –o addsolution –filename test.wsp 
Second, once the solution has been added to the solution store you can deploy it from the command line, or you can deploy it using the Central Administration user interface. Find the Solutions Management page by going to Start-->Administrative Tools-->SharePoint 3.0 Central Administration-->Operations, and in the Global Configuration section clicking Solution management. From there, click one of the listed solutions to see its status and to take action on it—like deploying it.

Alternatively, you can deploy the solution from the command line with the STSADM command deploysolution. If you want to deploy the test.wsp solution to the local system, issue this command:

STSADM –o deploysolution –name test.wsp –allcontenturls –local –allowgacdeployment –allowcaspolicies 
The allowgacdeployment and –allocaspolicies options are necessary only if you have indicated deploying an assembly to the GAC, or you have provided a CAS policy as a part of the solution file, respectively.

Hope this helps !!! 


SharePoint: Deploying WebPart/Feature as SharePoint Solution Package (.wsp file) - Part 3

Link to Part 1 : Creating Skeleton.
Link to Part 2 : Creating Features/Webparts
Link to Part 3 : Creating .ddf and Manifest.xml (current post)
Link to Part 4 : Using STSADM and Centeral Admin to add and deploy solution

Once we have all our feature and webparts ready its not time to create Manifest.xml file and .ddf file.

<?xml version="1.0" encoding="utf-8" ?>
<Solution xmlns="" SolutionId="{08A0C3C9-5586-4b1a-9598-B77DCAC64847}"

    <FeatureManifest Location="HandsOnFeature\feature.xml"/>
    <Assembly DeploymentTarget="WebApplication" Location="HandsOnWsp.dll">
        <SafeControl Assembly="HandsOnWsp, Version=, Culture=neutral, PublicKeyToken=35651a817c3c3a2e" Namespace="ClassLibrary1" Safe="True"  TypeName="*"/>

    <DwpFile FileName="handsOnWebpart.webpart" Location="HandsOnFeature/handsOnWebpart.webpart"/>

Manifest file defines the list of features, site definitions, resource files, Web Part files, and assemblies to process. It does not define the file structure—if files are included in a solution but not listed in the manifest XML file, they are not processed in any way. In addition, you can add a DwpFiles element to specify .webpart or .dwp files, or a ResourceFiles element to specify resource files, site definitions, application resources, and code access security policies.

DDF file
;*** Sample Source Code MakeCAB Directive file example
.OPTION EXPLICIT ; Generate errors
.set DiskDirectoryTemplate=CDROM ; All cabinets go in a single directory
.Set CompressionType=MSZIP;** All files are compressed in cabinet files
.Set UniqueFiles="OFF"
.Set Cabinet=on
.Set SourceDir=C:\Documents and Settings\rohillas\My Documents\Visual Studio 2008\Projects\HandsOn_Wsp\HandsOn_Wsp\ClassLibrary1\;

"Manifest.xml" Manifest.xml
"Features\HandsOnFeature\feature.xml"  HandsOnFeature\feature.xml
"Features\HandsOnFeature\element.xml" HandsOnFeature\element.xml
"Features\HandsOnFeature\me.aspx" HandsOnFeature\me.aspx
"Webparts\handsOnWebpart\handsOnWebpart.webpart" HandsOnFeature\handsOnWebpart.webpart
"Webparts\handsOnWebpart\handsOnWebpart.xml" HandsOnFeature\handsOnWebpart.xml
"bin\Debug\HandsOnWsp.dll" HandsOnWsp.dll

Note: For some reason relative part did not seem to work. Give it a shot !!

As you see, the manifest.xml file defines which files are parts of the solution that must be deployed on the front-end Web server. After you define the manifest.xml file, compile it into a CAB file with all the other required files. This is done by using the MAKECAB.EXE command-line utility. When you use this tool, you must define a .ddf file that instructs MAKECAB.EXE which files to include in the output CAB file.

The basic format of a DDF file is that of a text file. It contains one command per line. A line beginning with a single period is considered to be a command. Generally the first command is .OPTION EXPLICIT. For those of you familiar with Visual Basic, you'll recognize this sequence of words, which in this case means that if there's a problem processing the file MAKECAB should exit and report the error. The other commands that you'll use at the top of every DDF file that you're using to create a solution are:

1) .Set CabinetNameTemplate – Specifies the name of the output file—in this case, WFInspector.wsp

2) .Set DiskDirectoryTemplate=CDROM – Indicates that all of the CAB goes into a single directory

3) .Set CompressionType=MSZIP – Indicates that all of the files will be compressed into CAB files

4) .Set UniqueFiles="ON" – Indicates that all of the files referenced must be unique

5) .Set Cabinet=On – Use cabinet files

6) .Set DiskDirectory1=. – Use the current directory for the output CAB file 

In my next post I will discuss about building and deploying solution file.

SharePoint: Deploying WebPart/Feature as SharePoint Solution Package (.wsp file) - Part 2

Link to Part 1 : Creating Skeleton.
Link to Part 2 : Creating Features/Webparts (current post)
Link to Part 3 : Creating .ddf and Manifest.xml
Link to Part 4 : Using STSADM and Centeral Admin to add and deploy solution

Once we have out skeleton ready we can start filling it with features, webparts, assemblies, pages, etc...

Lets start with creating a feature:
create similar file structure as shown in figure above (this is bcoz, ddf file maintains mapping based on this file structure) 

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns=""
         Description="Hands On Feature"
    <ElementManifest Location="element.xml"/>
    <ElementManifest Location="handsOnWebpart.xml"/>
    <ElementFile  Location="me.aspx"/>
    <ElementFile  Location="handsOnWebpart.webpart"/>

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="">
   Title="Hands On Custom Actions"
   Description="Getting up and going with inline code" >
    <UrlAction Url=""/>

  <Module Name="mymodule" List="101" Url="Pages">
    <File Url="me.aspx" Path="me.aspx" Type="GhostableInLibrary">      
        <AllUsersWebPart WebPartZoneID="TopZone" WebPartOrder="1">
          <![CDATA[ <WebPart xmlns="" xmlns:iwp=""> <Assembly>HandsOnWsp, Version=, Culture=neutral, PublicKeyToken=35651a817c3c3a2e</Assembly> <TypeName>ClassLibrary1.handsOnWebpart</TypeName> <FrameType>None</FrameType> <Title>Hands On Webpart</Title> <iwp:ImageLink>/_layouts/images/homepage.gif</iwp:ImageLink> <iwp:AlternativeText>$Resources:core,sitelogo_wss;</iwp:AlternativeText> </WebPart>]]>        

creating a webpart: 
in a similar fashion create webparts structure as shown in figure above:

    public class handsOnWebpart : Microsoft.SharePoint.WebPartPages.WebPart 
/*inherit your webpart class from 'Microsoft.SharePoint.WebPartPages.WebPart' as sharepoint fails to load webpart on aspx pages which are not derived from 'Microsoft.SharePoint.WebPartPages.WebPart'. If you recall, in our element.xml we created a module element which contains file element refering to aspx file, which further contains AllUsersWebPart element specifying webzone ID and other details. Now, if our webpart was defived from 'System.Web.UI.WebControls.WebParts.WebPart' sharepoint would throw error on feature activation*/
        public handsOnWebpart()

        protected override void CreateChildControls()

            // TODO: add custom rendering code here.
            System.Web.UI.WebControls.Label label = new System.Web.UI.WebControls.Label();
            label.Text = "Hello World - Generate via Hands On Webpart (with DLL placed in web app bin)";

dwp file (webpart file): this file is referenced in manifest.xml
<?xml version="1.0" encoding="utf-8" ?>
  <webPart xmlns="">
      The following Guid is used as a reference to the web part class, 
      and it will be automatically replaced with actual type name at deployment time.
      <type name="70C2E501-C221-4ca3-91DB-78A4785DA79D" />
      <importErrorMessage>Cannot import WebPart1 Web Part.</importErrorMessage>
        <property name="Title" type="string">WebPart1 Web Part</property>
        <property name="Description" type="string">WebPart1 Description</property>

handsOnWebpart.xml: this file referenced in feature.xml
<?xml version="1.0" encoding="utf-8" ?>
<Elements Id="70C2E501-C221-4ca3-91DB-78A4785DA79D" xmlns="" >
  <Module Name="WebParts" List="113" Url="_catalogs/wp">
    <File Path="handsOnWebpart.webpart" Url="handsOnWebpart.webpart" Type="GhostableInLibrary" />

In my next post I will discuss on how to create ddf file, manifest file, add and deploy wsp solution.

Friday, September 19, 2008

SharePoint: Deploying WebPart/Feature as SharePoint Solution Package (.wsp file) - Part 1

Link to Part 1 : Creating Skeleton (current post)
Link to Part 2 : Creating Features/Webparts
Link to Part 3 : Creating .ddf and Manifest.xml
Link to Part 4 : Using STSADM and Centeral Admin to add and deploy solution

Today, I want to discuss about, how to provision WebPart/Feature as SharePoint deployable solution (i.e. "WSP" file). 
Before we start please make sure you have following pre-requisites:
  1. Visual Studio 2005/2008
  2. Microsoft Cabinet SDK (Download from here)
  3. Microsoft.SharePoint.dll
In this article I'll walkthrough creating:
  1. WebPart (name: handsOnWebpart)
  2. Add new item in SiteActions
  3. Add an "me.aspx" page in Pages Library
  4. Add webpart (handsOnWebpart) on "me.aspx" page
All the above functionality is achieved by wrapping under Feature (name: HandsOnFeature), which is packaged as ".wsp" file.

Following is step by step instructions as how to create a deployable .wsp file:

1. Create a Visual Studio 2005/2008 C# empty project

2. Unzip Microsoft Cabinet SDK (for simplicity sake we will unzip under root project folder)

3. Create following solution structure


Features folder will contain all features

WebParts folder will contain all webparts

DDF file will contain all instuctions for MAKECAB.EXE to create wsp and cab file.

Manifest file will contain all binding information required by SharePoint during installation

4. Make entry in post build event to run MAKECAB.EXE via command line to generate .wsp and .cab file.

Note: Only .wsp file is required for SharePoint deployable solution. We are creating .cab file for our ease so as we can open it and view the file hierarchy.

"$(ProjectDir)makecab.exe" /f "$(ProjectDir)tt.ddf" /D CabinetNameTemplate=test.wsp /D DiskDirectory1=wsp

"$(ProjectDir)makecab.exe" /f "$(ProjectDir)tt.ddf" /D /D DiskDirectory1=cab

Once solution is successfully build, we will see two new folders in bin/debug directory:
  • wsp : contains .wsp file
  • cab : contains .cab file
What have done till now is created a skeleton for our solution.

In my next post I will discuss on how to create ddf file, manifest file, feature, webpart.

Monday, September 15, 2008

SharePoint - using SPLimitedWebPartManager to create WebPart Connections

Scenario: A .wsp solution is deployed on SharePoint Server, which has publishing feature running on it. A new site is created based on a "site definition" as defined by Onet.xml (deployed in 12 hive directory by .wsp file). Doing so, number of new webparts available in WebPart gallery and hundereds of publishing pages based on different layout pages. 

Problem Statement: What I want is, weparts should be populated in all content pages (which in turn are derived from layout pages) along with connections binding them together. 

Solution: SPLimitedWebPartManager to rescue. There are multiple ways to achive the
desired result.

Method 1 : When provisioning a site
Method 2 :  When activating a feature
Method 3 : If content pages are based on layout pages, then add inline code/web control/user control in layout page

Method 1,2 and 3 are just delivery boys. What follows is the actual implementation of business case.

Comming right to the point, one should laverage functionality of SPLimitedWebPArtManger to add and associate webparts. Lets breakdown entire process in 3 simple steps
  1. Fetch WebParts
  2. Add WebParts
  3. Create WebPart Connections
1. Fetch WebPart

 private System.Web.UI.WebControls.WebParts.WebPart
SPWeb web, String webPartName)
SPQuery query = new SPQuery();
  // CAML query fetch list item with name equal to webPartName
query.Query =
"<Where><Eq><FieldRef Name='FileLeafRef'/><Value Type='File'>" +webPartName + "</Value></Eq></Where>";

SPList webPartGallery = null;
// webpart gallery is available at root web only
            if (null == web.ParentWeb)
// This is the root web.
webPartGallery = web.GetCatalog(
  SPWeb fetchRootWeb = web;
  // fetch root web
    fetchRootWeb = fetchRootWeb.ParentWeb;
                webPartGallery = fetchRootWeb.GetCatalog(
// pass query object to item collection
SPListItemCollection webParts = webPartGallery.GetItems(query);

String typeName = webParts[0].GetFormattedValue("WebPartTypeName");
String assemblyName = webParts[0].GetFormattedValue("WebPartAssembly");
ObjectHandle webPartHandle = Activator.CreateInstance(
assemblyName, typeName);

WebParts.WebPart webPart =
return webPart;

Once we have the webpart, all manipulations with a web part on a page are governed by theSPLimitedWebPartManager class, which is a scaled down version of SPWebPartManager class designed to do the same thing but without HTTP context available.

2. Add WebPart

Once we have the webpart, code below then adds it to the specified page into the target web part zone
        public string AddWebPart(
SPWeb web,
String pageUrl,
String webPartName,
String zoneID,
int zoneIndex)
using (System.Web.UI.WebControls.WebParts.WebPart webPart =
FetchWebPart(web, webPartName))
using (SPLimitedWebPartManager manager = web.GetLimitedWebPartManager(
pageUrl, PersonalizationScope.Shared))
manager.AddWebPart(webPart, zoneID, zoneIndex);
return webPart.ID;

3. Create WebPart Connections

Finally all what's left is connecting the web parts. Again SPLimitedWebPartManager comes at help here. The method AddWebPartConnection() first locates consumer and provider web parts by their unique IDs, which were captured earlier at a time of placing the web parts on a page; next it iterates through provider and consumer connection points to find the ones specified in the XML configuration file. By the way, these are the same as the constructor parameters used with ConnectionProviderAttribute and ConnectionConsumerAttribute types, which are used to decorate methods participating in a web part connection. When both connection points are determined we can call the SPConnectWebParts() method of SPLimitedWebPartManager to create the connection. 

public void AddWebPartConnection(
SPWeb web,
string pageUrl,
string providerWebPartID,
string consumerWebPartID,
string providerConnectionPointName,
string consumerConnectionPointName)
using (SPLimitedWebPartManager manager = web.GetLimitedWebPartManager(
pageUrl, PersonalizationScope.Shared))
System.Web.UI.WebControls.WebParts.WebPart provider =
System.Web.UI.WebControls.WebParts.WebPart consumer =

ProviderConnectionPointCollection providerPoints =
ConsumerConnectionPointCollection consumerPoints =

ProviderConnectionPoint providerPoint =

foreach (ProviderConnectionPoint point in providerPoints)
if (String.Equals(
providerPoint = point;

ConsumerConnectionPoint consumerPoint =

foreach (ConsumerConnectionPoint point in consumerPoints)
if (String.Equals(
consumerPoint = point;


Hope this helps !