Configuring Feature Components
A Feature can include any number of files, but it must include a 
Feature.xml file. The Feature.xml file, or Feature manifest, is the driver of the Feature, and this is the first file SharePoint looks at when invoking a Feature. It includes the high-level attributes, or properties, of the Feature, including Feature scope, references to other supporting Feature files, Feature dependencies, and assembly references deployed as part of a Feature.
| Note | If a Feature does not include a |
Features are organized in folders under the Features directory on the Web front-end server. In addition to the Feature.xml file, Features can include subfolders and supporting files, such as element files that include, for example, event handler references, ASPX pages deployed as part of the Feature, ASCX files, dynamic-link libraries (DLLs), and RESX files.
In this section, you'll review the attributes and configuration of the Feature.xml file, as well as supporting element files. The upcoming sections will demonstrate how elements can be leveraged to make changes directly to your SharePoint sites.
Feature.xml File
The Feature.xml file is the core file of a Feature. It includes the identifying GUID, title, and scope of the Feature. This includes information such as whether the Feature will be made available to an entire SharePoint farm or a site collection. SharePoint uses the Feature.xml file to deploy the Feature and identify any supporting files, including any custom assemblies associated with the Feature. For example, a developer might have created a programming solution as part of the Feature that performs certain actions when the Feature is installed or activated. Such a solution is associated with the Feature.xml file in the ReceiverAssembly attribute by including the solution's assembly reference.
An example of a basic Feature.xml file, including its top-level attributes, is shown in the following code block:
<Feature xmlns=http://schemas.microsoft.com/sharepoint/ Title="Name of Feature" Description="Feature Description" Scope="Web" Hidden="FALSE"> <ElementManifests> <ElementManifest Location="Elements.xml" /> </ElementManifests> </Features>
Table 26-1 provides an overview of Feature.xml attributes. You'll learn more about these attributes and how you can apply them in the "Creating Features in Visual Studio 2005" section of this chapter.
| Feature attribute | Description |
|---|---|
| Id | The globally unique identifier (GUID) for the Feature, in Registry format. |
| Title | The name of the Feature. It's important because it makes the purpose of the Feature easily identifiable. It can be up to 255 characters in length. |
| Description | (Optional) Describes what the Feature does. |
| Version | Specifies the version of the Feature. |
| Scope | Specifies where the Feature will be deployed and made available-that is, server farm, Web application, site collection, or Web (site). |
| Hidden | Determines whether the Feature will be visible in the Feature administrative user interface. This option toggles between False and True. False is the default. Set this option to True to hide the Feature from administrative user interface. |
| AlwaysForceInstall | (Optional) If True, any updates to the Feature are installed within the given scope without manual intervention during updating. Removes the need to add the -force parameter to the stsadm.exe command line when redeploying a Feature. |
| DefaultResourceFile | (Optional) The resource file the Feature uses for additional configuration details. |
| ImageUrl | (Optional) The URL to an image you want to have associated with the Feature in the Feature administrative user interface. |
| ReceiverAssembly | (Optional) The strong name of the assembly that handles events for the Feature.[*] |
| ReceiverClass | (Optional) The fully qualified, case-sensitive name of the class that handles events for the Feature. |
| ActivationDependencies | (Optional) The Feature IDs of any dependent Features-that is, Features that depend on the Feature being activated before they can be activated. |
| ElementManifests | The relative path to associated element files for the Feature. This can include more than one element file. |
|
[*]The ReceiverAssembly attribute in the | |
Open table as spreadsheet
Element Files
Element files are supporting files for a Feature. They are referenced in the Features.xml file in the <ElementManifests> element tag-for example:
<ElementManifests> <ElementManifest Location="location\Elements.xml"/> </ElementManifests>
Element files define the functionality of a Feature, such as including an additional button in a form, or list, toolbar, as shown in Figure 26-1, where an additional button named Site Help has been added.
Figure 26-1: Example of Feature enhancement to list toolbar Site Help button
Functionality is included in element files via element tags. For example, you use the Receiver element to include, or register, a custom event handler as part of a Feature. Or you use the Custom Action element to include a URL on a page in a SharePoint site-for example, a URL to a special event, which you can remove at a later stage. The Module element is used to include pages as part of your Features, such as ASPX or HTML pages.
Throughout this chapter, examples may refer to element files as "Elements.xml". However, you do not need to use this name for the element files deployed as part of a Feature. For example, if you review the default Feature AnnouncementsList, you'll notice the ListTemplates subdirectory includes an element file named Announcements.xml. You can also have more than one element file per Feature. For example, you might want to devote one element file to defining the Custom Action elements and have another element file to define the workflow or Content Type elements for a Feature.
Element Examples
In the following example, the Receiver element is used in an element file to register the assembly and class for an event handler, which will be deployed as part of the Feature and applied to a specific list type in a SharePoint site:
<Receivers <ListTemplateOwner="GUID" ListTemplate> <Receiver> <Name>Event Handler</Name> <Type>ItemDeleting</Type> <SequenceNumber>1000</SequenceNumber> <Assembly>AssemblyName, Version=1.0.0.1, Culture=neutral, PublicKeyToken=tokennumber</Assembly> <Class>ClassName</Class> <Data></Data> <Filter></Filter> </Receiver> </Receivers>
Each element includes attributes to define the element; each attribute is exposed through the SharePoint schema using the Visual Studio IntelliSense feature. In the case of the Receiver element, the <Type> attribute defines the type of event handler. In this case, the event handler is of type ItemDeleting, a synchronous event handler used to trap an action as it occurs, such as stopping a user from deleting a file from a document library or list. The <ListTemplateOwner> attribute includes the GUID of the list template Feature, and the <ListTemplateId> attribute is the base type of the list. For example, 101 is the base type for document library, so the event handler will apply to the document library. A sample of an event handler included as part of a Feature deployment is included in the "Creating an Event Handler Feature" section of this chapter.
The Module element is used to provision files to a site. Here is an example of the Module element and its configuration:
<Module Name="HelloWorld" Path="" Url=""> <File Url="HelloWorld.aspx" Type="Ghostable" IgnoreIfAlreadyExists="FALSE" </File> </Module>
The <File Url> attribute refers to the location of the file when it is provisioned-for example, in the Feature folder. The <File Type> attribute can be Ghostable, GhostableInLibrary, or Unghost. This setting determines whether the changes are stored to the database or cached from the original template on the Web front-end server when customizations are made to the file or page using SharePoint Designer 2007.
Table of Elements
Table 26-2 lists the available elements for element files. Elements used in supporting element files are governed by the scope of the Feature-for example, Web or Farm. The available elements for each scope are described in this chapter in the "Administrating Feature Scope" section‥
| Element name | Element description |
|---|---|
| Content Type | Contains a schema definition, for example to define metadata, templates and workflow, which you can reuse and apply to multiple list, and document library, definitions. |
| Content Type Binding | Content type binding enables you to provision a content type on a list, or document library, defined in the |
| Control | A delegate control contains a registration controls installed on a Web page. This allows you to replace existing controls, such as the Windows SharePoint Services search control, with your own custom control. |
| Custom Action | You can define custom actions in your Feature, such as:
|
| Custom Action Group | A group of custom actions. |
| Document Converter | A document converter takes a document of one file type and creates a copy of that file in another file type, such as from a Microsoft Office Word 2007 Document to Web Page format. |
| Feature/Site Template Association | Binds a Feature to a site definition or template so that sites provisioned from that site definition or template include the Feature. |
| Field | Contains a field, or column, definition that can be reused in multiple lists. |
| Hide Custom Action | Hides a custom action that has been added through another custom action. |
| List Instance | Provisions a SharePoint site with a list which includes specific data. |
| List Template | A list definition or template, which defines a list that can be provisioned to a SharePoint site. |
| Module | Includes files which are included when provisioning sites, such as .aspx or .html files. |
| Receiver | Contains an item event handler receiver registration, such as a column, list or Web event handler. |
| Workflow | Defines a workflow for a list, or document library. |
| More Info | For a more complete listing of element attributes, including details on Features schemas, visit the Windows SharePoint Services 3.0 Software Development Kit, which can be found on the Microsoft Download Center at http://www.microsoft.com/downloads/details.aspx?FamilyId=&displaylang=en. |
Resource Files
Resource files are essentially schema files that include XML elements to define and populate provisioned pages, Web Parts, and lists. They are installed as part of the default SharePoint installation on the Web front-end server at the following path:
-
%SystemDrive%\Program Files\Common Files\Microsoft Shared\web server extensions \12\Resources
Resource files further compartmentalize the SharePoint framework by placing key configuration details into smaller, pluggable files, and they afford developers the opportunity to further customize extensions such as custom lists by centrally defining custom data and value parameters.
The following example of using the default resource files includes the default DocumentLibrary Feature.xml file, which references the default resource file, core.en-US.resx, as its resource file. This is denoted in the Title, Description, and DefaultResourceFile attributes shown in the following code block:
<?xml version="1.0" encoding="utf-8" ?> <!-- _lc _version="12.0.4017" _dal="1" --> <!-- _LocalBinding --> <Feature Id="" Title="$Resources:core,documentlibraryFeatureTitle;" Description="$Resources:core,documentlibraryFeatureDesc;" Version="1.0.0.0" Scope="Web" Hidden="TRUE" DefaultResourceFile="core" xmlns="http://schemas.microsoft.com/sharepoint/"> <ElementManifests> <ElementManifest Location="ListTemplates\DocumentLibrary.xml" /> </ElementManifests> </Feature>
The core resource file in the Resources folder includes data and value tags for populating the Feature Title and Description:
<!-- DocumentLibrary Feature --> <Data Name="documentlibraryFeatureTitle"> <Value>Document Libraries</Value> </Data> <Data Name="documentlibraryFeatureDesc"> <Value>Provides support for document libraries for a site.</Value> </Data>
The DocumentLibrary Feature element file, DocumentLibrary.xml, includes the attributes DisplayName and Description as part of its ListTemplate definition. Corresponding data values in the core resource file are used to populate those attributes. The DocumentLibrary.xml file is shown in the following code block, with the reference to the core resource file for both DisplayName and Description:
<?xml version="1.0" encoding="utf-8" ?> <!-- _lc _version="12.0.4017" _dal="1" --> <!-- _LocalBinding --> <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <ListTemplate Name="doclib" Type="101" BaseType="1" OnQuickLaunch="TRUE" SecurityBits="11" Sequence="110" DisplayName="$Resources:core,doclibList;" Description="$Resources:core,doclibList_Desc;" Image="/_layouts/images/itdl.gif" DocumentTemplate="101"/> </Elements>
The core resource file populates DisplayName and Description from the data and value tags shown here:
<Data Name="doclibList"> <Value>Document Library</Value> </Data> <Data Name="doclibList_Desc"> <Value>Create a document library when you have a collection of documents or other files that you want to share. Document libraries support features such as folders, versioning, and check out.</Value> </Data>
Developers can create custom resource files to add more configuration details to custom lists and document libraries, and then reference those custom resource files in custom Features.
| Important | The default resource files should not be modified because this can destabilize existing, default functionality. Instead, create new resource files for any custom purposes. For example, you could copy the core resource file, rename it, and modify the XML parameters according to your needs. |
For additional information on resource file configuration, refer to the .NET Framework 2.0 Software Development Toolkit (SDK) and search for Resources in RESX File Format. The SDK can be found on the Microsoft Download Center at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=.
EAN: 2147483647
Pages: 299