“And I don’t want to see any copy/paste action between these files…keep them in sync with each other OK?!”…the boss tells you.
The main issue is that these files are not included in “your” part of the source control, hence they reside somewhere else in the file structure and you have to find a way to seamlessly include them in your SP solution before you can deploy it.
Hey, I can use “..add existing item” you say and add the files as links to the actual files. Then if I update the files (or someone else does) it will update the original ones also since we’re just adding links to the original ones.
OK, so let’s try that approach then and see what happens then.
Expect to see problems…
So here’s an example on how this setup might look from a source file (windows explorer) perspective.
You have one folder called JSLib which holds the company.js file which is the file that we will try to include into the other folder johanleino.com which is the actual VS SharePoint project.
What comes to mind here is to use a mapped folder synced to “Layouts” and add the company.js file in there.
So, there is a mapped folder in the project already. I’m adding the company JSLib files into that folder (subfolder actually that’s called company-x under johanleino.com…please note that screenshot doesn’t show exactly that though).
So, here I’m picking the company.js file from the JSLib folder from the “root” of the source file structure. It’s added as a link into my SP project’s mapped folder named Layouts/johanleino.com/company-x
You can see that VS “marks” that file with an icon telling me that the file is linked (the original is not actually in that place…it’s just a link).
So, are we finished now??
Let’s look in the WSP package explorer designer:
All files that are in mapped folders (at least a mapped folder that deploys to layouts) are so-called template files (deployment type = templatefile in VS SP tools).
This means that they are deployed somewhere beneath the TEMPLATE directory in the SharePoint root files. This is however not something you can see from the package explorer in VS (as you can see from the image above).
To see the actual deployment location we have to look at the properties for the file (company.js) or package and look in the WSP:
As you can see it looks kind of weird (Layouts\..\..\JSLib) and you can’t change that value.
That’s the inconvenience!!
And you guessed right…trying to deploy the file will result in:
…no trace of the company.js file or the subfolder I placed it in.
Solution: How to trick Visual Studio
OK, so mapped folders are normally great since we can hook it up directly to a folder in SP root files and it displays like a folder in the VS IDE, it syncs the files, etc etc…
But in this case where we need more control over the deployment we’ll use a “regular” SPI.
…add new item on so on (I’ll go with empty element type).
I’ve named the SPI JSLib and I’ve completed all the same steps as for the mapped folder approach (add existing item, browse to the file, add as links…etc) so that company.js is included as a link in the SPI.
The next step is to tell VS SP tools that we want to deploy that file as a template file, like:
Oops…you might get an exception (just ignore it though).
As a result of that exception (or so) you have to “handcraft” the path beneath the TEMPLATE directory where you want this file to end up (which you couldn’t do with the mapped folder files):
The final step is to use the package explorer to include the SPI in the packaged output (WSP).
“Move from the left side to the right side…”
Package –> Deploy …and:
A plus is that the CKS:Dev tools extensions for VS 2010 will also pick this up (hence, you can still use the “copy to SharePoint root command” or “Auto copy on save”)
Enjoy and hope the MS fixes this until VS11 releases…right!?