Inconvenient: Files inside mapped folder which links to existing items


You’re working on a SharePoint site for company x in Visual Studio 2010. Your boss tells you that company x uses a graphical profile (css + images) and some javascript files that you “must” include in the new site. The boss also informs you that if you make any changes to these files they have to stay in sync with the originals.

“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…

Mapped Folders


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 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…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/


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!?


, , ,

  1. #1 by Hugo Häggmark on January 20, 2012 - 08:30

    Great post!

    Wouldn’t another approach be to have all company specific css and javascripts in a central Nuget package?


    • #2 by Johan Leino on January 20, 2012 - 09:49

      Yes, that’s of course yet another option!! Although my real intention with this post was to show that there are things lacking in the VS2010 SP tools.

  2. #3 by Anatoly Mironov on January 20, 2012 - 09:47

    Great post! It is so often I need to include some files which have to be synced.

  3. #4 by DizzyBlack on October 5, 2015 - 12:06

    This was helpful. Thank you.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your 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: