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):
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).
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:
- I want to make a point that you have to look out in these kinds of situations.
- 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):
Solution: you basically have two options
- Include the SPI inside a feature (as shown before)
- Use the package manager UI to add it to the WSP (shown below)
Now, look at the packing explorer again and you should see this:
And subsequently after deploying your package the file appears at the correct place in the root files directory on the server/s.
Two basic things to take away from this post are:
- Get to know your deployment type options (i.e. how does the type of SPI affect your package)
- Get to know the packaging explorer and the management UI (it might be useful to alter the VS packaging system sometimes)