When a Feature gets installed

Have you ever thought about the Features folder and when a folder will be created for one of you features? Well, I did 🙂

Why is this relevant, anyway? To be able to activate a feature on a given scope, it has to be installed first. That’s why.

  <td valign="top">
    <strong>Result</strong>
  </td>
</tr>

<tr>
  <td valign="top">
    stsadm -o addsolution
  </td>
  
  <td valign="top">
    The solution is added to the farm. Features are not available
  </td>
</tr>

<tr>
  <td valign="top">
    stsadm -o deploysolution
  </td>
  
  <td valign="top">
    Feature folders are created and the Features are available for activation
  </td>
</tr>

<tr>
  <td valign="top">
    stsadm -o installfeature
  </td>
  
  <td valign="top">
    A feature with ID xyz has already been installed in this farm.  Use the force attribute to explicitly re-install the feature.
  </td>
</tr>
Action

Great. After deploying the solution, the feature is automatically installed and can be used. I did expect this, because installing a feature is a rather uncommon task.

Here comes another one. What if you add a feature to an existing – and deployed solution – and perform an upgrade?

  <td valign="top">
    <strong>Result</strong>
  </td>
</tr>

<tr>
  <td valign="top">
    stsadm -o upgradesolution
  </td>
  
  <td valign="top">
    Adds the new feature folder
  </td>
</tr>

<tr>
  <td valign="top">
    stsadm -o activatefeature
  </td>
  
  <td valign="top">
    Feature with Id &#8216;4520d607-699b-4025-b605-5f988c97b368&#8217; is not installed in this farm, and cannot be added to this scope.
  </td>
</tr>
Action

Ups. Did you expect the result? The feature has to be installed first!

Conclusion

If you add a feature to a solution, make sure the features gets installed prior usage! There are two ways

  1. Install the new feature
  2. Retract and Redeploy the solution