Getting to know your SharePoint 2010 packaging options

image

Have a look at the image above.

If you’re familiar with working with SharePoint 2010 projects in VS2010 you should know that when you add a new SPI (SharePoint Project Item), like a module|content type|empty item|etc, it’s by default added to a feature of the “correct” scope.
Waldek Mastykarz has more information about this, and a way around it, if you’re interested.

The image below tries to illustrate what happens to your items (in this example an element file) if the feature is removed from the package (if the feature is removed, the SPI is removed from the package…by default that is):

image

So who cares you might say. When will I ever need to pay attention to this?

Well, have a look at the following scenario then…

Issue: adding a root file

What I want to accomplish now is to add a configuration file to the 14/CONFIG folder upon deploying the WSP.
This will be accomplished by adding the configuration file to an empty SPI and setting the deployment type to root file (like shown below).

image

Note that I also needed to change the “default” Path property value to CONFIG (+ subdir if you want one) to make the file end up in the correct place among the 14” folders.

But hey wait a minute now!!

…you might say. You could just use a mapped folder right?

Well, yes you could but there are two reasons why I can’t do that:

  1. I want to make a point that you have to look out in these kinds of situations.
  2. I’m (in an upcoming post I’m working on) using a configuration transformation on this file and I don’t want my CONFIG directory cluttered with configuration files (I’ll show you what I mean in an upcoming post) since you can’t control which files under a mapped folder that are actually included in the WSP ouput. (only code files C#+VB are removed by default)

OK, back on track. If you now package this project up as WSP (without including the SPI in a feature as the default option is) there will be no trace of the configuration file in the WSP (as the packing explorer below shows):

image

Solution: you basically have two options

  1. Include the SPI inside a feature (as shown before)
  2. Use the package manager UI to add it to the WSP (shown below)

image

Now, look at the packing explorer again and you should see this:

image

And subsequently after deploying your package the file appears at the correct place in the root files directory on the server/s.

image

To summarize

Two basic things to take away from this post are:

  1. Get to know your deployment type options (i.e. how does the type of SPI affect your package)
  2. Get to know the packaging explorer and the management UI (it might be useful to alter the VS packaging system sometimes)

, ,

  1. Leave a comment

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

%d bloggers like this: