Home Library Learn Downloads Support Community
Sign in | United States - English | |
3 out of 12 rated this helpful - Rate this topic

Feature Element (Feature)

Windows SharePoint Services 3

Defines a Feature to activate or deactivate at a specified scope.

Copy 

<Feature
  ActivateOnDefault = "TRUE" | "FALSE"
  AlwaysForceInstall = "TRUE" | "FALSE"
  AutoActivateInCentralAdmin = "TRUE" | "FALSE"
  Creator = "Text" 
  DefaultResourceFile =  "Text"
  Description = "Text" 
  Hidden = "TRUE" | "FALSE"
  Id = "Text"
  ImageUrl = "Text"
  ImageUrlAltText = "Text"
  ReceiverAssembly = "Text"
  ReceiverClass = "Text"
  RequireResources = "TRUE" | "FALSE"
  Scope = "Text"
  SolutionId = "Text"
  Title = "Text"
  Version = "Text" >
</Feature>
Attribute Description

ActivateOnDefault

Optional Boolean. TRUE if the Feature is activated by default during installation or when a Web application is created; FALSE if the Feature is not activated. This attribute equals TRUE by default. The ActivateOnDefault attribute does not apply to site collection (Site) or Web site (Web) scoped Features.

In general, Farm-scoped Features become activated during installation, and when a new Web application is created, all installed Web application-scoped Features in it become activated.

AlwaysForceInstall

Optional Boolean. TRUE if the Feature is installed by force during installation even if the Feature is already installed. For example, if set to TRUE, Feature installation callouts will always fire anytime a user tries to install the Feature (even if it is already installed) by using either the scanforfeatures or installfeature command-line operation. This attribute equals FALSE by default. The AlwaysForceInstall attribute affects Features of all scopes.

AutoActivateInCentralAdmin

Optional Boolean. TRUE if the Feature is activated by default in the Administrative Web site, site collection, or Web application. This attribute equals FALSE by default. The AutoActivateInCentralAdmin attribute does not apply to Farm-scoped Features.

Creator

Optional Text.

DefaultResourceFile

Optional Text. Indicates a common resource file for retrieving Feature XML resources. If you do not specify a resource in the file, Windows SharePoint Services looks by default in \12\TEMPLATE\FEATURES\FeatureName\Resources\Resources.<Culture>.resx. However, if you want to provide a shared core resource file for all the Features in your application, you can specify an alternate file through which to access resources by using DefaultResourceFile. For example, if you set DefaultResourceFile="MyFile", Windows SharePoint Services looks in \12\Resources\MyFile.<Culture>.resx to retrieve localized resources for your Feature.

Description

Optional String. Returns a longer representation of what the Feature does.

Hidden

Optional Boolean. This attribute equals FALSE by default.

Id

Required Text. Contains the globally unique identifier (GUID) for the Feature.

ImageUrl

Optional Text. Contains the site-relative URL for an image to use to represent the feature in the user interface (UI).

ImageUrlAltText

Optional Text. Contains the alternate text for the image that represents the feature.

ReceiverAssembly

Optional Text. If set along with ReceiverClass, specifies the strong name of the signed assembly located in the global assembly cache from which to load a receiver to handle Feature events.

ReceiverClass

Optional Text. If set along with ReceiverAssembly, specifies the class that implements the Feature event processor.

RequireResources

Optional Boolean. TRUE to specify that Windows SharePoint Services check whether resources exist for the Feature by verifying that the standard "sentinel" resource for the Feature is present for a particular culture.

The resource file is named according to the format <Feature Directory>\Resources\Resources.<Culture Name>.resx, where <Culture Name> is the name that identifies the culture. Windows SharePoint Services 3.0 supports the following formats for culture names:

ll-CC

ll-Ssss-CC

Culture name examples:

en-US English (United States)

de-DE German (Germany)

fr-FR French (France)

ja-JP Japanese (Japan)

sr-Latn-CS Serbian (Latin, Serbia)

The Internet Engineering Task Force (IETF) language tag format is ll(l)-Ssss-CC, where:

  • ll(l) denotes the required two-letter language identifier (or three-letter if there is no ISO two-letter code for the language).

  • Ssss denotes an optional script identifier.

  • CC denotes an optional region identifier.

The RequireResources attribute allows you to constrict the visibility of certain Features depending on whether resources exist in a particular language for the Feature.

NoteNote:
Windows SharePoint Services does not use the file specified by the DefaultResourceFile attribute, if there is one, as a backup file for verifying support of a particular language for a feature.

If the file is not present for the language of a particular Web site or site collection, then two behaviors can occur:

  • The Feature will be hidden from the user interface for activation of Features in the Web site or site collection if the corresponding resources for the language are not available.

    Keep in mind that the RequireResources attribute is enforced in the user interface only. A Feature without resources for a particular language can still be activated for a Web site through command line operations with stsadm.exe or through the object model.

    Windows SharePoint Services does not enforce RequireResources for Features that are part of a larger site definition. If you supply, for example, a Thai version of a site definition by putting a webtempThai.xml in \12\TEMPLATE\1054\XML, you must verify that each Feature contained in the folder has the appropriate resources.

  • In general, Windows SharePoint Services ensures that user interface extension components of the Feature do not show up in Web sites that do not have resources, but there are exceptions. Even if you do a careful job of setting RequireResources and not deploying site definitions unless all Features have resources in them, Features can still show up in sites where resources are not available.

    As an example scenario, assume that you have a custom Feature with resources for two languages that provides custom toolbar buttons and site settings links, and that you have provisioned a new site collection with a root Web site in one of the languages. Then, after downloading and installing the language pack for a third language, you provision a new subsite in this third language under the original root Web site. If RequireResources is not set to TRUE, the custom Feature will attempt to fall back and use fallback resources (in other words, those defined as Resources\Resources.resx, with no culture.)  If there are no fallback resources, Windows SharePoint Services will render empty strings. However, if RequireResources is set to TRUE, user interface extension components of the Feature (for example, those defined through a CustomAction, ListTemplate, or FeatureSiteTemplateAssociation element) will not show up in subsites if no resources are available, so that the custom links and site settings will be automatically hidden.

Setting this attribute only applies to activating Features through the user interface, and not through STSADM.EXE command-line operations or the object model.

Scope

Required Text. Specifies the scope in which the Feature can be activated and contains one of the following values: Farm (farm), WebApplication (Web application), Site (site collection), Web (Web site). For information about scope, see Element Scope.

SolutionId

Optional Text. Specifies the solution to which the Feature belongs.

Title

Optional Text. Returns the title of the Feature. Limited to 255 characters.

Version

Optional Text. Specifies a System.Version-compliant representation of the version of a Feature. This can be up to four numbers delimited by decimals that represent a version.

Windows SharePoint Services supports only low-order ASCII characters, and no spaces, for Feature folder and file names.

For an example of how this element is used, see Feature.xml Files.

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
ActivateOnDefault

The ActivateOnDefault attribute causes different behavior depending on the Scope of the feature. If the attribute has the value "TRUE" or is omitted:

  • Farm: The feature is activated on installation of the feature
  • WebApplication: During installation of the feature it is not automatically activated on existing web applications. The feature is automatically activated for new web application created after the feature has been installed.
  • Site: Not applicable
  • Web: Not applicable

How do you auto activate a feature, at Site level ???

History
ImageUrl

It's probably worth mentioning that the ImageUrl attribute is relative to the _layouts/Images folder. 

ImageUrl="/MyOrg/featurelogo.gif"


will be found at

  http://<sitename>/_layouts/Images/MyOrg/featurelogo.gif


Also, the standard image size is 31x22.

History
Deploying Assembly To Site (Null Exception)
I recently built a .wsp solution which specified 'ReceiverAssembly' and 'ReceiverClass' attributes.

When deploying to a target Site Collection via Central Administration 'Solutions Management', it was returning a 'Null' Exception error.

Turns out that in the class inheriting from SPFeatureReceiver, I was initializing a Public Variable = null, which messed with the Event Handler registration!
History
Installing/Uninstalling a Feature with different scopes causes duplicate custom action menu

I don't know how this could happen, but it's clearly not by design I guess.

I've found some issues accidentally playing around with Scope attribute in Features.

The steps described below will cause some unexpected results in Site Actions menu.

First issue:

1. Install a simple custom action feature with the scope 'Farm'.

2. Change the scope to 'WebApplication'.

3. Uninstall the feature.

4. Install the feature again.

You will get a message saying that the feature is already activated at Farm level, and you will have the custom action menu in every site as if it was installed at Farm level. But in the Web Application features, the feature is inactive.

Second issue:

1. Install a simple custom action feature with the scope 'Farm'.

2. Change the scope to 'WebApplication'.

3. Uninstall the feature.

4. Change the scope to 'Site'.

5. Install the feature.

At this point, you will see the same result as above; custom action menu in every site, but the feature in site collection features is inactive.

6. Activate the feature in site collection features.

Now you have two custom action menus in Site Actions.

History
xmlns attribute
I found it necessary to add an xmlns="http://schemas.microsoft.com/sharepoint/" attribute to the Feature node. Otherwise I got an error on deploying the feature.
History
Reply to DrCaesar
You are missing the activation step. Custom Actions are cached. You need to iisreset to fix this. In all cases, the scope of a feature should not be changed after it has been installed. To change the scope, you have to deactivate all feature instances, uninstall the feature, apply change, then re-install.
History
Error in documentation ?

I think there's a "don't" missing..?

Shouldn't it be:

"DefaultResourceFile
Optional Text. Indicates a common resource file for retrieving Feature XML resources. If you don't specify a resource in the file, ..."

History