Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Let me preface this by saying that I am brand new to Sharepoint, so the answer to this question may be obvious.

I have a blog feature on one of my Sharepoint sites that I need to make changes to. There is one "master" ghostable xml file that contains the web part layouts for each page in my blog. I am running the following commands to update the feature on my site:

-stsadm.exe -o upgradesolution -name blogfeature.wsp -filename newblogfeature.wsp -allowgacdeployment -immediate
-stsadm.exe -o deactivatefeature -name blogfeature -url http://myblogsite
-stsadm.exe -o activatefeature -name blogfeature -url http://myblogsite

This has been the only way that I have been able to deploy some updates that were made to the ghostable xml file. The problem is, however, that after I run these commands, each of my pages have two versions of all of the webparts listed in the ghostable xml file for each page. If I reactivate the feature and activate it again, each page will have 3 versions of each webpart etc.

Am I using the proper commands to update a feature on my blog site? Is there a way to update the blog site and simply replace the webparts on each page?

Thanks in advance!

share|improve this question
add comment

2 Answers 2

If you're using SharePoint 2010 and want to play by it's rules then you shouldn't deactive/activate features when upgrading. Instead you should be using FeatureUpgrading see Chris O'Briens serie: Feature upgrade (part 1) - fundamentals.

If you're still at 2007 and/or allow users to activate/deactivate your feature, then you might want to consider adding the web parts using code in a feature receiver. Then you can perform any kind of check you want before adding the web parts.

share|improve this answer
add comment

Unfortunately, this is the way web part deployment works. Whenever situations like this have come up, I've always been forced to include custom deployment code to work around it.

If it's the layout or properties that are changing and it's practical to do so, deleting the target pages first will work. If the layout and properties aren't the things that are changing, perhaps separate into different features so that you can selectively activate?

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.