PANVEGA’s Blog

DotNet Development, SharePoint Customizing, Silverlight, MS Infrastructure and other tips and tricks

Problems when deactivating Webparts

Posted by PANVEGA on April 14, 2008

Problem:

When a feature which contains a web part file is deactivated, the .webpart file in the database will not disappear.  People can continue to add the web part to their pages.  If you need the .webpart file to go away, you’d need to add some code in the deactivation event to delete the file. When a solution is retracted, the underlying files and assemblies behind it should be removed from front ends.

The .webpart file will still exist in the database, but it won’t function as the backing file is gone.  And web part instances will fail, as their backing assembly is gone.

When I deactivate a feature, the webparts still stick around.  Why is that?
When a feature is deactivated, different things happen depending on what is in the feature.  To understand this, keep in mind there are two types of elements in a feature:


•    provisioned elements. These are things like files, lists, and content types which are added into an spweb.
•    defined elements. These are elements that are only defined within the feature – they never get into the database and are not customizable
Defined elements disappear when the feature is deactivated.

Here a code snippet from a custom Webpart code. You see the WP properties are shared to all users who have of course the rights to. The custom properties were stored into the DB. However if you change the PersonilizationScope the same problem still remains.

#region Wepart Properties
private string xmlUrl = “”;
[Personalizable(PersonalizationScope.Shared),
WebBrowsable(true),
WebDisplayName(“Path XML File”),
WebDescription(“Path XML File”),
Category(“Extentions”)]
public string XmlUrl
{
get { return xmlUrl; }
set { xmlUrl = value; }
}

You see the properties when modifying the WP properties in SharePoint.

Provisioned elements can be customized by end users.  Therefore, they are not automatically deleted when the feature is deactivated.  If no end user customization is expected (eg you don’t expect that a user will customize a webpart file) you should consider explicitly deleting the web part in your feature deactivation callout.

Same with the Ghosting (Uncustomized) and unghosting 12er to DB. When editing the file, Sharepointcopies the content into the DB and deletes the reference there.


With dependencies, if a feature has activation dependencies, when a feature is deactivated its hidden dependents will be deactivated according to a “last one turns out the lights” rule. So, if you deactivate the Team Collab feature (which depends on the hidden doclib feature), and no other active feature depends on it, the doclib feature will be deactivated as well.

When you still have a instance of your Webpart in the page, however deactivating and uninstalling the feature. One easy way to get rid of it is to delete each instances in all pages.

In a nutshell, fully removing some capabilities (web parts, list instances, etc.) from a sharepoint farm can be difficult, and it typically involves writing some code to delete things.

Here is an example WebPartGalleryCleanUpCode method when deactivating the feature :

Read more about SPFEATURERECEIVER Class in one of my previous post

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
using (SPSite _SPSite = properties.Feature.Parent as SPSite)
{
using (SPWeb _SPWeb = _SPSite.RootWeb)
{
SPList _SPList = _SPWeb.Lists[“Web Part Gallery”];

for (int i = _SPList.ItemCount – 1; i >= 0; i–)
{
string webpartName = _SPList.Items[i].Name;
webpartName = webpartName.Substring(0, webpartName.IndexOf(‘.’)) + “WebPart”;

if (properties.Feature.Definition.DisplayName == webpartName)
{
_SPList.Items[i].Delete();
break;
}
}
}
}
}

Advertisements

One Response to “Problems when deactivating Webparts”

  1. - said

    Thank you for that nice article.
    For a german MOOS 2007 your method needs to be changed like that:

    public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
    {
    using (SPSite spSite = properties.Feature.Parent as SPSite)
    {
    using (SPWeb spWeb = spSite.RootWeb)
    {
    SPList spList = spWeb.Lists["Webpartkatalog"];
    foreach (SPListItem spListItem in spList.Items)
    {
    String webpartName = spListItem.Name;
    webpartName = webpartName.Substring(0, webpartName.IndexOf('.'));
    if (properties.Feature.Definition.DisplayName == webpartName)
    {
    spListItem.Delete();
    break;
    }
    }
    }
    }
    }

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: