Removing *.webpart from the Web Part Gallery in FeatureDeactivating Event

Removing the web part from the Web Part Gallery when the feature is deactivating is the most obvious thing that anyone would wanna do. Now please dont tell me you'd tell your client to go to the Gallery and knock it off himself.

The obvious solution that we are looking at is doing something in FeatureDeactivating. Might be accessing the Web Part Gallery like a List and knocking off the Item based on some query.

So let say we have a webpart (i would reference the Recent Documents Web Part as i speak). We want to query the Web Part Gallery and knock this guy off.

Initially i did a stupid query like this:
. I Know you must be feeling sorry for me.. even i am. This is not the solution..or is it?? We can very well have webparts in the Gallery with same Title.. who'll stop your client from doing it.



The only fool proof method here i can see, or apparently see, is reading the *.webpart or *.dwp and checking for 5 part type signature



Well, lets do it then, read the SPFile of the current ListItem and knock the guy off! This is the *.webpart we are talking about

.

Well, lets go ahead and read the type element and knock it off.



(I forgot the counter++ in above snippet..well, wrote it only for illustration you see)

I happily installed the feature and tried playing around with Site Collection Feature
I activated the Feature and webpart got loaded (if you dont know.. you dont need to do anything to load the *.webpart in the Gallery... Feature Activation does it automatically for you for reasons i dont know.. i guess its made that way in WSS 3.0.. well i am not the conceptual god in sharepoint.. ask that to Andrew.

I now deactivated this feature and then went to the gallery....What the heck!!!.. this guy is still here

On debugging i found this out:



Tried out few stupid things just to content meself that i m trying to crack something here. Wait a minute!!... Holy Cow!!.. i know why is this happening.. i exactly know why is this happening!!.



My God!!.. dont tell me know i have to get all the uid's and schema's to initiate a XmlNameSpaceManager before I feed it to my XPathDocument

No i wont do it.. I rather would prefer to write a recursive code block for this:



Then use it in the code like this:



You can also go a little ahead and not hard code the attribute value like this:

Sharepoint.Webparts.RecentItems.DocumentsAggregator,
CoolStuffs.Webparts.RecentItems, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=66a50cd71f898803

If your FeatureReceiver is in the same project as your webpart, which i think it would, in almost all cases, then you can use reflection to do that.



The Code sample doing this can be found in my Recent Documents Project's FeatureReceiver