Understanding features

Question

So when I make a sp2010 solution, it includes a "feature".

Am I right in thinking that a feature is a deployable package? I have a Sharepoint 2010 solution in Visual Studio 2010, with lots of webparts etc. Can I have one feature and group 3 out of 5 SPIs together (E.g. ones which may be dependent on each other), with a certain feature name, then deploy the remaining two SPIs (I am assuming it MUST be then a different feature name - or unique, in other words).

Is this the right way of thinking about features?

Answer 1

You can think of Features as a plugin that can be activated or deactivated in the several scopes (farm, webapplication, site, web). Depends on these scopes a feature can contain different elements. Also you can define where an element is accessible. For excample, if a feature with web part has web scope, this web part is available only on a site. If a feature has site scope, this web part is available on all sites of site collection. As a good practice features should be activated from higher lebel to lower level(Farm -> WebApplication -> Site -> web).

Answer 2

You can think of Features as a mechanism for adding elements to a target site or site collection .The types of elements that can be added to a site include menu commands,link commands, page templates, page instances, list definitions, list instances, eventhandlers, workflows and so on. So,You can include multiple SPIs in a feature.

At minimum, a standalone feature comprises of a unique Feature folder with a Feature.xml(called feature manifest) which can be deployed using stsadm commands ( installfeature, activatefeature )

You can automate the process of installing features with a Solution Package (it is a cabinet file with an extension of .wsp) Using a .wsp package, you can deploy a set of one or more features, automatically copying the files and folders to every front-end server from a centralized management console.

Answer 3

A package (WSP) contains one or more features, and each feature can contain SPIs. If you have a couple of SPIs that are related you should bundle them into a feature.

In addition to SPIs you may have some other changes that may also need to be done with a feature receiver. In some cases you will have features that do not contain any SPIs and only deploy changes through the feature receiver(s).

It is also important to understand that Features can have a dependency on other features. It is also possible to have hidden features. The hidden features cannot be deactivated through the UI, and are typically controlled via feature receivers attached to other features.