Kirk Evans Blog

.NET From a Markup Perspective

SharePoint: Don’t Forget to Uninstall the Feature

SharePoint: Don’t Forget to Uninstall the Feature

Rate This
  • Comments 4

A question came up today that I thought was interesting and I hadn’t fully examined before. 

If you retract and delete a solution in SharePoint 2007 without first uninstalling its features, are turds left behind?

The short answer: If you retract and delete a solution without deactivating and uninstalling the feature for each deployed scope, then turds are left behind both in the file system and in the config database.

To demonstrate this, I created a simple ItemEventReceiver, which uses a feature that is scoped to the web level.  I deploy the solution to a web application, and then it is available to the individual web sites to activate.  The code for this is unimportant, it’s just a solution that contains a feature scoped to the web level.  Here are the commands that I run to add my solution to the solution store, deploy it to a web application, and activate the feature for a web site within the web application.

stsadm -o addsolution -filename featuretester.wsp
stsadm -o deploysolution -name featuretester.wsp -allowGacDeployment -immediate -url http://moss-1
stsadm -o execadmsvcjobs
stsadm -o activatefeature -id fb9375d5-07ae-4835-b64c-83441c806691 -url http://moss-1

This is pretty standard stuff.  You probably already know that this creates a folder in the SharePoint root for our feature in the 12/Template/Features folder.

image

This also deploys our assembly to the Global Assembly Cache.

image

I wonder, though, does the feature exist only in the file system, or is it now part of the configuration database?  We check the configuration database, and yep… there’s an entry in the dbo.Features table for our feature.

image

Let’s see what happens if we activate our feature for a new web.

stsadm -o activatefeature -id fb9375d5-07ae-4835-b64c-83441c806691 -url http://moss-1/sitedirectory/team

As we expected, there are now two entries in the dbo.Features table.

image

Cleaning It Up The Right Way

Cleaning this up the right way is simple, we reverse all of our steps until now.  We need to deactivate the feature for each scope that we activated it for.

stsadm –o deactivatefeature –id fb9375d5-07ae-4835-b64c-83441c806691 -url http://moss-1
stsadm –o deactivatefeature –id fb9375d5-07ae-4835-b64c-83441c806691 -url http://moss-1/sitedirectory/team
stsadm –o uninstallfeature –id fb9375d5-07ae-4835-b64c-83441c806691

This will remove the entries from the configuration database and remove the entries from the file system in a supported manner.

What Happens if I Don’t Clean It Up The Right Way?

OK, now our real question.  Imagine we are still at the point where everything is deployed and activated.   We now have artifacts in the configuration database, and we have artifacts in the file system for every server in our farm.  What happens if we retract the solution and delete it?  Are turds left behind in the database and file system, or does SharePoint get rid of them for us?

stsadm -o retractsolution -name featuretester.wsp -immediate -url http://moss-1
stsadm -o exeadmsvcjobs
stsadm -o deletesolution -name featuretester.wsp

Here, we are retracting the solution from the web application and then deleting the solution from the solution store.  Let’s go check our artifacts on the server again to see what remains.

First, we look in the file system.  Hmm… the files are still there. 

image

I know what you’re thinking, “so what?  they’re just files and folders.”  Fair enough, simply adding folders and files to the SharePoint root doesn’t do anything unless we tell SharePoint about it using an stsadm command.  Let’s go look at the Global Assembly Cache.

image

As you can see, the entry for our assembly is no longer in the GAC.  When we deleted the solution, the assembly was removed as part of the process (just as it is added when you call addsolution). 

OK, so far it left behind files and folders, removed an entry from the GAC… is it clean?  Well, no.  SharePoint still has pointer records to the features in the configuration database.

image

At this point you may be thinking, “so what?  it left behind turds, but my farm is still running ok.”  Effectively, all we did was remove the DLL from the GAC and the WSP from the solution store.  The individual web sites still think there’s an ItemEventReceiver deployed.  That’s why we find the following types of errors when we go to a list where an ItemEventReceiver was bound

02/02/2011 22:40:54.78    w3wp.exe (0x193C)    0x1EDC    Windows SharePoint Services    General    75fe    High    Failed to determine definition for Feature with ID 'fb9375d5-07ae-4835-b64c-83441c806691'.  Skipping this feature for element querying consideration.   

What’s happening is that there is a feature that is orphaned because its implementation is missing.  It shows up in the ULS log to let us know that it thought there was a feature deployed here, but something’s gone wrong.

Let’s look at one more thing… upgrading.  After SP2 for SharePoint 2007, a new command was added to stsadm to check for potential upgrade issues.  We run the command:

stsadm -o preupgradecheck

This is a benign operation, meaning it makes no changes to your farm at all.  It simply runs through a list of known issues that occur when upgrading from SharePoint 2007 to SharePoint 2010 and validates your farm.  You can see in the command window output that we have one error, colored red.

image 

After the tool is run, it generates a .HTM file that describes the errors it encountered and provides more information on each potential issue. 

image

Right there at the top, we see that our missing feature has caused a potential blocking issue for upgrade. 

What About SharePoint 2010?

Oh, astute reader!  You are thinking about the upgrade process and wondering if this has been “fixed” in SharePoint 2010.  The first thing to address is that there’s really nothing to fix, as this isn’t a bug, it’s working just as it was intended to.  The proper sequence is to deactivate and uninstall the feature, as shown in the section above “Cleaning It Up the Right Way”.  This behavior did not change for stsadm commands in SharePoint 2010, they remain unchanged so that administrators can continue managing their farms without completely changing all of their scripts.

But wait, SharePoint 2010 has all these great PowerShell cmdlets!  Yes, that’s true, there are a ton of new PowerShell cmdlets that give you even greater flexibility for managing SharePoint.  But the simple design fact remains that you still have to explicitly deactivate the feature at the specified scope using the cmdlet Disable-SPFeature. Once the feature has been deactivated at the given scope, you can use the new PowerShell cmdlet “Remove-SPSolution” that collapses the minimum of 3 separate stsadm commands into 1 single PowerShell cmdlet that removes the solution from the solution store.

For More Information

Features and solutions cmdlets (SharePoint Server 2010)

Stsadm command-line administration

  • Great post Kirk.  For our SharePoint publishing site we actually use the setup.bat file that is generated by VSeWSS 1.3 to deploy our solution packages.  Sadly we have to make several modifications to the setup.bat file to ensure our solution packages deploy successfully as you described above.  

    This includes the following...

    - Changing the -local tag to -immediate for the deploysolution and retractsolution command.

    - Adding the command "stsadm -o execadmsvcjobs" to run the timer jobs after a deploysolution and retractsolution command

    - Adding the install feature command before any activate feature command.

    - And I usually add the -force attribute to the activatefeature, installfeature, and deployfeature commands for good measure.

    I guess what I find interesting about this all is that when I run the command "stsadm -o deletesolution -name <Name of Solution Package>", my script will sometimes NOT delete the solution from the solution store.  I notice that this only happens when I have to deactivate and uninstall features that are still part of this solution package I am trying to delete.

    Can you explain, in your example above, how you were able delete the solution from the solution store even though some features were still activated and installed or is there something I am missing?

  • @Craig - funny you mention the setup.bat script, I am actually working on a post that talks about -local versus -immediate and why F5 deployment doesn't work in VSeWSS if you are developing on a farm with multiple servers... because it uses -local from the service application, skipping the timer job, which fails to deploy to the other servers.

    In the organizations I have worked with, they won't accept a batch file for deployment.  Developers provide the WSP to the operations team, and they run through their own scripts for adding the solution, deploying it, and activating the features.  

    I didn't add any additional command lines or calls, I ran each line and then did the screen shot as I typed the blog post, trying to make sure I didn't miss any steps.  

  • Thanks for this blog. It helps alot.

  • Thank you Krik, it's really helpful. We have faced a some issues, when we have missed adding 'uninstall' commend for deployment scripts

Page 1 of 1 (4 items)
Leave a Comment
  • Please add 4 and 5 and type the answer here:
  • Post
Translate This Page
Search
Archive
Archives