A better alternative to SharePoint Mapped Folders
February 27, 2013
In the previous article
I wrote about wrongness of the SharePoint Mapped Folders, and today I'll try to
elaborate this topic and introduce a very good replacement for them.
Are they really so bad?
Actually I'm not quite against Mapped Folders. I don't say they will not work.
I don't say you absolutely must not to use them at all... Well, they have
limitations and hardly any benefits, but that's not the main problem. The essential problem with
SharePoint Mapped Folders is that they allow and even encourage ASP.Net
developers to work as they were working in ASP.Net...
SharePoint is a huge 10+ years old enterprise development platform based on
ASP.Net. SharePoint relates to ASP.Net as ASP.Net relates to C#... In ASP.Net you
don't use pure C# to yield HTML to the page, right? You use markup and controls
and page life cycle and databound controls and all this stuff they built for you.
Then why do you keep using pure ASP.Net when working with SharePoint?!
Because Microsoft wants to pull you in! :) It sells you SharePoint Mapped
Folders, it sells you SPGridView and it sells you the idea: "you know ASP.Net?
great, you can develop solutions for SharePoint!". It is really a good bait. But
I think nobody in MS really thought anyone can keep jumping at this bait for
In fact it is never enough to know ASP.Net to develop efficiently in
SharePoint. You must learn tens of SharePoint features and intended usage and limitations for each
of them, and how SharePoint is built and how it works and how it scales. The reward is that the
development time is decreased greatly (compared to ASP.Net approach) and you
concentrate on UX and business value and make really useful and convenient
portals which save a company money rather than devour them...
And returning to the SharePoint Mapped Folders, this evil thing definitely
encourages developers to keep ASP.Net ways and essentially - write the same code SharePoint
Development Team had already written and tested years ago on thousands of
different configurations. It encourages
them to code from scratch hardly using SharePoint at all, and it is a great
shame when such people name themselves "SharePoint developers" :(
So yes, SharePoint Mapped Folders are really bad if you think about it. And
btw, we have much better alternative!
SharePoint Mapped Folders is essentially a way to store files, pages, controls
and so on. But SharePoint virtual file system serves the same purpose. Why not
use it? Even for administration pages, why not?
Create modules, put files there, put modules inside features, that's all. You
can either deploy your files into libraries or leave them out in plain folders
if you don't want users to touch them.
Important advantage is that you can access your files and pages through SharePoint Designer.
You can connect to your customer site remotely and do a quick fix if it's necessary,
and you know that some customers don't allow RDP access... You can use
versioning and checkin/checkout features, so that first you verify your changes
yourself, and only then check them in and make them available to all users.
Comparing site pages (deployed through modules) and application pages (deployed
via SharePoint Mapped Folders), the biggest benefit of the former is
that you can switch a site page to edit mode, add/remove webparts and so on. You
can't do this in case of application pages, they don't support webpart zones and
dynamic webparts, and OOTB webparts put straight to application pages markup aren't
supported to work there as well (in fact they will work to some extent, but not
Thus, by having some administration page as a site page rather than application page, you can, say, add a quick announcement by
adding Content Editor Webpart to the page, and so on. No need to recompile or deploy anything.
Some other features include versioning and approval (if you deploy files to
document libraries), "Revert to site definition", links tracking (see
BackwardLinks property of SPFile) and many more. It's a wonder how many
interesting features SPFile object includes!
And yes, you perfectly can have code behind there if you wish, by deploying a
custom sandboxed visual webpart or a user control there (though in most cases I would prefer to use some OOTB
As you see, there are really many benefits when you deploy files to SharePoint
via modules instead of using SharePoint Mapped Folders.
And you will get even more once you start leveraging SharePoint OOTB webparts and
controls like DFWP, CQWP, XLV and so on (which by the way are not supported on application
pages), and webpart connections, and all other beautiful SharePoint features on
your site pages. Based on my experience, OOTB webparts are sufficient for
implementing 90% of business requirements, and you can do it tens times faster
and the result will be completely integrated with all the rest of SharePoint,
which is really amazing! :)
When SharePoint Mapped Folders are better
I honestly tried to think out some use cases when application pages are better
than site pages or when having files in layouts is preferrable to storing them
in database, but can't! :(
Performance benefits are negligible, and correctly configured Remote Blob
Storage allows you to eliminate such benefits completely.
Availability throughout the farm is more disadvantage than advantage, because I
assume my page should work only for the sites there my feature is activated.
Then you use SharePoint Mapped Folders, you make your files available in every
site and site collection in the farm instantly. You just cannot scope them.
Some SharePoint features require adding files to CONTROLTEMPLATES folder (like
RenderingTemplates), but most of those features are very old and usually there
are better ways to achieve the same goal. And well, a couple of controls in
ControlTemplates is OK.
You can use ashx files in SharePoint Mapped Folders, but in most cases you can
live without ashx. Last time I used ashx to upload files to
SharePoint asynchronously, though I'm still convinced that there was some better
way to do it, but we were tough on schedule and so I preferred ashx approach...
Fetching SPContext automatically by current URL is probably the best benefit we have for
application pages, though it is not a big deal to grab the context manually from
either query string params or HTTP referrer or whatever...
What else? If you have any ideas regarding to that, please drop a comment below,
let's discuss. But honestly, I don't see any big benefits in using SharePoint
Mapping Folders and/or Application Pages.
I've been working with SharePoint Mapped Folders and creating application pages
for about two years in a row, from my very start with SharePoint. But for
about 1.5 year now, I've been using modules and site pages
instead, and my solutions became much better and I'm able to implement them much
faster. I wish you the same :)