It’s A Pkg Deal

Persisting Custom SharePoint Feature Settings in a VSeWSS Project

The Visual Studio extensions for Windows SharePoint Services (VSeWSS) provide a pretty steady leg up to developers tasked with SharePoint 2007 customization. Not having to bake your own XML files from scratch or cram a custom deployment batch script into your post build step really gives one that peppy modern feeling. But for all the solid that the extensions do us, there are still one or two things I would change if it were up to me. One of these is how the pkg folder is handled.

Feature Configuration 101 (Or, Jump Back To This Part If You Didn’t Follow That At All)

When developing for SharePoint, the Feature is the key building block of your operation. The settings for each feature live, as one might guess, in its feature.xml file. A VSeWSS project automatically generates this file based on element manifests or Feature Receiver code it finds within. When the Package or Deploy commands are issued on the project, a folder named pkg is populated with these and other files necessary for deployment to a SharePoint site.

To that end, this pkg folder is treated much like the bin folder generated for most projects in Visual Studio–it is not automatically included in the project. This would be just ducky for a lone SharePoint developer shoving things straight out to a production site; but many of us work on teams with other developers. This usually involves trust falls, paintball outings, and source control.  While each of these can indeed involve a pkg in some way, the latter will be our raison d’être du jour.

Get On With It

As-is, the generated feature.xml file is enough to get you off the ground when deploying your custom SharePoint creation. However, there are many settings therein which may be necessary to alter manually; for example, to give your feature some professional polish like a title and description readable by humans and SharePoint administrators. The SharePoint Extension gods have therefore benevolently bestowed upon us the WSP View, for navigating and editing said files:

Editing feature.xml in the WSP View

It feels just like making real growed-up code changes.  The fine print on this is that your updates will be made locally, and they will be deployed properly to your local SharePoint site (presumably on your development virtual machine), but when you check in your project’s code for the other developers on your team to see, your alterations to anything in the pkg folder will not be included.

Fix it Already (Or, Skip To This Part If You’re Wearing a Bluetooth Headset and You’re Totally in a Hurry)

The solution to this is to simply include the pkg folder in the project, once it has been generated:

  1. Right-click your project, and select Package. This will create/update all of the necessary files and folders in pkg.
  2. With the project name highlighted in the Solution Explorer, click the Show All Files button.
  3. Right click on the pkg folder and select Include in Project.

Include in Project

Visual Studio will then treat these files as first class source, and control them by checking them in alongside your other files already enjoying this status. Once you have done this, the other devs on your team will finally be able to recognize your brilliance, and will probably stop dropping you or shooting you in unpleasant places during your other team-building activities.

Advertisements

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