SharePoint Lessons Learned

Problems with SPFeatureCollection.Add

#1) SPFeature.Add ignores access denied failure

My major problem with SPFeatureCollection.Add is that it does not report failure due to access denied.

In the case of attempting to add a site collection feature, when the current user is not a site collection administrator, SPFeatureCollection.Add will create a new SPFeature object in the collection and return it, although the feature has not actually been activated on the site collection. I expected to be able to work around this by creating a new SPSite object (pointing to the same site collection) and checking its features collection, but no -- the new feature appears there as well.

For this reason, SharePoint Solution Installer does not report activation failures -- because they seem undetectable at the API level.

#2) SPFeatureCollection Add & Remove act differently than GUI if feature receiver not found

My second problem with SPFeatureCollection, Add and Remove both, is that they succeed silently in the face of feature receiver misconfiguration. From the GUI, activating or deactivating a feature missing its feature receiver assembly will fail, with a fairly descriptive error message (if custom errors are disabled). However, SPFeatureCollection Add and Remove will both actually succeed in this case.

This can be useful; it is a workaround to deactivate a feature which cannot be deactivated from the GUI.