Moving files in Visual Studio and the SharePointProjectItem.spdata file

While mucking around the CKS:Development Tools Edition Visual Studio 2010 extension for SharePoint, I inadvertently created a new master page from the Starter Master Page (CKSDev) template in an existing VS module:

Neither VS nor SharePoint seemed to object to this arrangement—likely because the module in question was otherwise empty—but, as an experiment, I decided to move the CKS:Dev master page SPI into the project (and the top-level MasterPages module) nonetheless, making the nested CKS:Dev container obsolete.

This wasn't a good idea because subsequent attempts to build the package failed with the error "Could not find the file 'c:\…PageLayouts\StarterMasterPage1.master". Omg, what to do and why is trying to find these files in the project root?! I briefly pined for the good ol' .ddf file from 2007 days and then slapped some sense back into myself.

To begin fixing the problem, I first had to click the Show All Files button in the Solution Explorer window to reveal the SharePointProjectItem.spdata file in the root-level module (note the CKS:Dev inner master page module has its own .spdata file, which is empty after the move):

This is an XML file and its structure is quite basic; I'd describe it as a mini project file for the module in question as it lists the source files in the module along with their targets, and types.

Interestingly, the Source values specified all started with "..\" but inspecting a similar file from an un-modified module simply listed each file names; I assume Visual Studio helped out during the move to add this additional path information.

Removing the "..\" prefix fixed the problem and suggested to me the SharePoingProjectItem.spdata file may prove fragile during project refactoring. Sure enough, moving the files back to their original home added a spurious MasterPages\ prefix to each file and wreaked havoc all over again.

Moral of the story: manually edit the SharePointProjectItem.data file as required but beware Visual Studio may "fix" any of your changes.

One other thing to note: when I moved my files around, Visual Studio reset the properties on some of them. Most notably, Elements.xml file reverted to a Deployment Type of ElementFile instead of ElementManifest and the Build Action was set to Content. Modifying these properties also added the parent directory prefixes back to my .spdata file. Perhaps removing files from one location and adding them them back through the Add –> Existing Item… dialog is a safer way to approach this long-term if VS is going to continue meddling with things.

And just to add to the joy, one final bit of fun: a page layout added to the module in question was deploying fine; for the sake of producing the screenshot above, I excluded it from the solution, which also removed it from the files listed below the MasterPages module in the visual feature designer. While I assumed the feature designer would automatically update itself when I added the layout back to the module, I was wrong: the designer refused to update to reflect the inclusion of the page layout until I restarted Visual Studio! If this is a VS 2010 bug, it'll be one of several I've already filed with MS! Viva SP1!!!

If you found this post helpful, please support my advertisers.