Nearly every SharePoint project that involves some type of content management, whether it be using document libraries, custom lists, or published web content, we generally find ourselves needing to create one or more content types to deliver the designed solution to a client.  Up until this point, most often we have taken the most basic approach to creating content types in the past – performing the task through the built-in SharePoint UI.  While this methodology works, it can almost be thought of as the brute-force approach.  I make this comparison because while the built-in UI offers a working method for creating content types, and the underlying site columns that they are made up of, it lacks in providing any means to take those site columns and content types and move them elsewhere, or apply them to multiple site collections.

Another approach to building content types and site columns to leverage the built-in Features framework within SharePoint 2007.  While this method isn’t as glitzy, as it involves creating XML files instead of just pointing & clicking, it offers a much more portable, extensible deliverable.  Instead of going to a client and just manually building out the same site columns and content types in each & every site collection they require, we can create a single SharePoint feature that contains these definitions, and then activate it on each site collection after it is created, or take it one step further, and create a custom site definition based upon the site template the client wants to use for their sites, and configure the feature within it to be activated automatically upon site creation, or leverage the feature stapling framework as another approach to automatically activating this feature for new sites – what could be more streamlined, and error-proof than that?

My intent is for this posting to cover simply the process of creating a feature for defining site columns, since these are the fundamental building blocks of content types, then in forthcoming posts, discuss the process of bringing these site columns together into one or more content types, and finally how to take the built-in Team site definition, create a duplicate of it, and add our custom feature to it, to illustrate automatic feature activation. 

A SharePoint feature, is a module of functionality that can be enabled at specific scopes within a SharePoint farm, namely the farm level, web application level, site collection level, and site level.  SharePoint itself uses features for nearly everything it provides out of the box – the standard list definitions, the built-in site columns & content types, built-in web parts, and they are even used to define what is displayed on the Site Settings page and the Site Actions menu.  Each of the features, both built-in and custom ones, live within the “12” hive at 12\TEMPLATE\FEATURES, and each is contained within its own unique folder, whose name reflects the feature’s purpose.  Within this folder there is one and only one required file, whose name must be feature.xml.  This file defines the basic characteristics of the feature including its ID, name, description, activation scope, and visibility.  Additionally this XML file can define additional information that is specific to the feature itself, such as a receiving assembly, and potentially one or more element manifests.  Each element manifest that is defined is represented by an additional XML file that is also contained within the feature’s folder, and within these files is where the uniqueness of the feature comes out, as they can be used to define the set of files that the feature is going to inject into a given site, or the custom actions the feature will add to the Site Actions menu, or the site columns and/or content types that the feature will add to its targeted site, just to name a few.  Finally, in addition to the element manifest XML files, the feature’s folder can contain any number of other files and folders that are needed for the feature itself, based upon its intended purposes.

For our example feature, we will start with just two XML files in our feature, namely the required feature.xml file, and a single element manifest named AcmeSiteColumns.xml.  Let us begin by reviewing the contents of our feature.xml file:

<?xml version="1.0" encoding="utf-8" ?>
<Feature  Id="A5DA673C-FF79-427c-BBB4-422937F82FCB"
          Title="Acme Content Types"
          Description=""
          Version="12.0.0.0"
          Scope="Site"
          Hidden="FALSE"
          xmlns="http://schemas.microsoft.com/sharepoint/">
    <ElementManifests>
        <ElementManifest Location="AcmeSiteColumns.xml" />
    </ElementManifests>
</Feature>

A couple of the more important points about this to highlight are:

• Id – this must be a unique GUID for your feature.  New GUIDs  can be generated within Visual Studio using the Tools, Create GUID menu option.
• Title – this is the display name of the feature, as it will show up within SharePoint.
• Description – this is the descriptive text that will show up within SharePoint for the feature, on the listing page.
• Scope – this can be set to 1 of 4 possible values – Farm, WebApplication, Site (site collection), Web (site).
• We have one element manifest defined, using a filename of AcmeSiteColumns.xml

And the accompanying AcmeSiteColumns.xml file contains the following:

<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
    <!-- Acme Site Columns -->
    <Field ID="{9A77BCEB-5230-48f2-93ED-D87DAAEC6998}" 
           Name="ArticleHeadline" 
           StaticName="ArticleHeadline" 
           SourceID="http://schemas.microsoft.com/sharepoint/v3" 
           Group="Acme Site Columns" 
           DisplayName="Article Headline" 
           Type="Text" 
           Required="FALSE" 
           Sealed="FALSE">        
    </Field>

    <Field ID="{CB2E757E-3876-40c8-A720-C98063DBCC3D}"
           Name="ArticleAbstract"
           StaticName="ArticleAbstract"
           SourceID="http://schemas.microsoft.com/sharepoint/v3"
           Group="Acme Site Columns"
           DisplayName="Article Abstract"
           Type="Note"
           NumLines="6"
           Required="FALSE"
           Sealed="FALSE">
    </Field>

    <Field ID="{13480703-B260-4354-83DC-AA7AF22A629E}"
           Name="Classification"
           StaticName="Classification"
           SourceID="http://schemas.microsoft.com/sharepoint/v3"
           Group="Acme Site Columns"
           DisplayName="Classification"
           Type="Choice"
           Required="FALSE"
           Sealed="FALSE">
            <CHOICES>
                <CHOICE></CHOICE>
                <CHOICE>Public</CHOICE>
                <CHOICE>Internal</CHOICE>
                <CHOICE>Restricted</CHOICE>
                <CHOICE>Confidential</CHOICE>
                <CHOICE>Secret</CHOICE>
            </CHOICES>
            <Default></Default>
    </Field>

    <Field ID="{B022435C-D299-40fd-B071-5C9DF95F6F4F}"
           Name="DisclosureLevels"
           StaticName="DisclosureLevels"
           SourceID="http://schemas.microsoft.com/sharepoint/v3"
           Group="Acme Site Columns"
           DisplayName="Disclosure Levels"
           Type="MultiChoice"
           Required="FALSE"
           Sealed="FALSE">
            <CHOICES>
                <CHOICE>A1</CHOICE>
                <CHOICE>A2</CHOICE>
                <CHOICE>A3</CHOICE>
                <CHOICE>A4</CHOICE>
                <CHOICE>A5</CHOICE>
            </CHOICES>
    </Field>

    <Field ID="{DBBD4D5F-A390-414b-9BB2-1160C1B2E35E}"
           Name="Lifetime"
           StaticName="Lifetime"
           SourceID="http://schemas.microsoft.com/sharepoint/v3"
           Group="Acme Site Columns"
           DisplayName="Lifetime (yrs.)"
           Type="Number"
           Required="FALSE"           
           Min="0"
           Max="100"
           Decimals="0"
           Sealed="FALSE">
    </Field>

    <Field ID="{7B6905FB-6619-4276-AB3D-9A04A04D8806}"
            Name="ExpectedCost"
            StaticName="ExpectedCost"
            SourceID="http://schemas.microsoft.com/sharepoint/v3"
            Group="Acme Site Columns"
            DisplayName="Expected Cost"
            Type="Currency"
            Required="FALSE"
            Sealed="FALSE">
    </Field>

    <Field ID="{6AAD913B-D930-49b5-8BCD-99FAB8857257}"
            Name="ExpiresOn"
            StaticName="ExpiresOn"
            SourceID="http://schemas.microsoft.com/sharepoint/v3"
            Group="Acme Site Columns"
            DisplayName="Expires On"
            Type="DateTime"
            Required="FALSE"
            Sealed="FALSE">
    </Field>

    <Field ID="{D38E97DA-CD82-4a77-9086-3B97A6D61A92}"
           Name="Activated"
           StaticName="Activated"
           SourceID="http://schemas.microsoft.com/sharepoint/v3"
           Group="Acme Site Columns"        
           DisplayName="Activated"
           Type="Boolean"        
           Required="FALSE"
           Sealed="FALSE">
        <Default>0</Default>
    </Field>
</Elements>

As should be evident, we have defined eight (8) site columns, each of which is represented by a Field XML element in the file shown above.  In this set of site columns, I’ve attempted to illustrate the following basic built-in field types: Single line of text, Multiple lines of text, Choice (single value), Choice (multiple value), Number, Currency, Yes/No, and Date/Time.  Obviously I was not able to exhaust each potential option that is available within these field types, but I’ve attempted to provide a sampling of what is possible, to wet your appetite a bit.  Furthermore notice that each site column defines its own ID value which must be a unique GUID for each column you define, as well as a consistent, meaningful grouping name. 

Also, note the use of the Required and Sealed attributes.  The Required attribute is used to indicate if a given site column, when it is used, must require a value to be specified – each of my examples set this attribute to FALSE.  The Sealed attribute is a bit more interesting – this defines if the given site column is able to be modified within the SharePoint UI after it is created, such as to allow its choice values or other customizable options to be changed.  For some columns, restricting this might make sense, but in this example I’ve again set each one to a value of FALSE for this attribute.

To see the fruits of our work, we can browse to a SharePoint site where this custom feature has been activated within, and we should see the following on the Site Columns page:

As stated earlier, both of these files will live within a new folder that defines the feature.  I find it most beneficial to create an Empty Visual Studio project when creating features and other custom SharePoint artifacts, and within this project, create a folder hierarchy that mimics the “12”-hive structure, for the portions of it that are applicable to your solution.  In the case of this custom feature, this means creating folders for 12, TEMPLATE, and FEATURES, nesting them accordingly, to result in the following project structure:

In addition to the folder structure, you will also see a BAT file script named wsp.bat. This particular BAT file script contains the necessary commands to invoke WSPBuilder to bundle this feature into a solution package, and then activate the feature within a SharePoint site.  Based upon  your deployment needs, you may find it beneficial to modify the logic within this script to meet your own needs.  The contents of my deployment BAT file is as follows:

@ECHO OFF
@SET WSPPBUILDER="C:\Tools\WspBuilder\WspBuilder.exe"
@SET STSADM="C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\STSADM.EXE"
@SET SOLUTIONNAME=ContentTypeTest.wsp
@SET URL=http://sp2007dev
@SET FEATURE=AcmeContentTypes
  
ECHO Building Solution Package
  %WSPPBUILDER% -Excludepaths bin
  
ECHO Deactivate feature
 %STSADM% -o deactivatefeature -name %FEATURE% -url %URL%/sites/blank
  
ECHO Removing Existing Solution
 %STSADM% -o retractsolution -name %SOLUTIONNAME% -immediate -url %URL%
 %STSADM% -o execadmsvcjobs
 %STSADM% -o deletesolution -name %SOLUTIONNAME%

ECHO Installing Solution
 %STSADM% -o addsolution -filename %SOLUTIONNAME%
 %STSADM% -o deploysolution -name %SOLUTIONNAME% -immediate -url %URL% -allowGacDeployment -allowCasPolicies -force
 %STSADM% -o execadmsvcjobs

ECHO Recycling App Pool
 iisapp /a "SharePoint - 80" /r

ECHO Activate feature
 %STSADM% -o activatefeature -name %FEATURE% -url %URL%/sites/blank

I find it easiest to simply set up this script to be executed as a post-build event, this way once you have made changes to your XML files within the Visual Studio project, you can just build the project, and that will kick off this process, from which you can proceed to your site, and review the results.  Below identifies how my post-build event is configured:

Using this approach I’ve outlined for packaging up SharePoint artifacts is well worth it, as it provides a nice end-to-end means for taking a Visual Studio project and turning it into something that can be deployed to any number of SharePoint farms without any additional work.  My forthcoming posts on creating additional features and site definitions will employ a similar pattern, though I will refrain from explaining the details of it in those posts.

So with that said, you can see what I mean by saying that leveraging SharePoint Features to deploy custom site columns adds tremendous value to a project.  Not only does it allow development efforts for creating site columns to produce something that is re-usable, but it also formalizes the process, and makes it agnostic of the SharePoint farm that it is being deployed to.  There is absolutely no reason why a set of custom features that define an *entire* SharePoint build-out couldn’t be created, pulled together into a WSP solution package, and then at the client site just install the solution package, deploy it, and proceed to activate its contents as necessary.  In the next posting I’m planning on this topic, we will take the set of site columns we’ve defined here and create a content types that links them all together, again leveraging the feature framework for the entire process.