forge

SharePoint Features Aren’t Transacted Installers

I’m still working on workflows and SharePoint.  One of the things that I’ve been playing with is how you can use a standard default.aspx page as a workflow association or workflow initiation page.  I’ve developed a set of web parts that you can subclass from.  These web parts deal with all of the mundane details that you have to support to have a association page and initiation page.  It manages all of the form posting and performing the actual association or instantiation.

As a part of that process I developed a feature which used a Module node in the elements xml to deliver pages into the site (SPWeb) that the feature was activated in.  In those pages I added an AllUsersWebPart node which causes my web parts to be loaded on the page.  The feature has an activation dependency that causes the actual workflows to be activated.  The workflow feature itself is hidden so the users won’t see it when they are looking for features to activate.

However, one of the things that I noticed was that every time I deactivated and activated the pages I got another set of web controls.  In digging in I noticed that the page wasn’t getting removed from the SPWeb when I deactivated the feature.

Help Your SharePoint User

In conferring with some others, I came to understand that this is the intended behavior.  Features are not transacted installs.  If you want to remove something that was added from the feature from the site collection or site you have to write a feature receiver to receive the FeatureDeactivating event.  Yick.

The net of this is that you have to write code to delete things that you created with the CAML in the feature definition.  Luckily you can do it.

So the short of this is that you should not expect that when you deactivate a feature it actually does anything (much) to remove the feature.  I’ve been told that list instances behave the same way as modules but I’ve not tested it.