Editing Files in a WSP

Sometimes you don't have the Visual Studio project handy for a wsp--but you want to change something (settings, etc). I can remember trying this a while back and finding it tedious--having to resort to makecab and the like. The need came up again so I figured it was worth a search to see if anything had changed, and behold, there is an easier way now. Thanks to Grumpy Wookie for posting about a nice archiving utility, IZArc, and how to use it to edit wsp's. I found a slightly simpler process. The steps are basically:

• Rename the WSP to CAB
  
• Extract the wsp to a folder
  
• Edit the extracted files as needed
  
• Select all the files in extracted folder (Ctrl-A) and create a zip archive (this avoids the problem Grumpy Wookie ran into with IZArc not handling subfolders)
  
• Open the zip in IZArc and do Tools > Convert Archive and select Cabinet (.cab) as the Output Type to create it as a CAB
  
• Edit the created cab file to change it back to a wsp
  

You can download IZArc from CNet.

I wouldn't normally blog about something this trivial, but I figure the more blog posts on this, the better.

SharePoint Feature Scope Changes Ignored

The Problem

I ran into a situation where I had deployed a broadly scoped feature and then narrowed the feature scope down, but the feature was acting like it still had the original scope settings. The feature was a delegate control to deploy JQuery using the AdditionalPageHead delegate control, just like Jan Tielens described here. When I had the feature scoped to the site collection (Scope="Site"), it was auto-deploying across the site collection as expected. But then when I tightened the scope down to specific websites (Scope="Web") and added a Scope="false" to make it require manual activation, it was behaving as if the it was still scoped at the site collection and was still auto-deploying. This continued even when I completely deleted the solution.

The Fix

After completely deleting the solution, I updated the solution and feature with new GUIDs. Thereafter, it behaved as expected. It seemed to behave like some remenant of the solution wasn't fully removed by from the solution store even though the solution was deleted. Here's a related forum posting on the issue. If it was something I did wrong, then I doubt changing the feature and solution GUIDs would have fixed it--that's my story anyway.

I'll also mention that I tried developing this with VSeWSS 1.3 but was frustrated by it always creating an assembly (even for the "empty" project template) which couldn't be removed without breaking things. I fell back to STSDEV which is remains my tool of choice.