Top5 SharePoint features to avoid
February 19, 2013
Many years with SharePoint, and I certainly have many small secrets which help me
to successfully struggle through notorious and widely blamed SharePoint thorns and
And one very good thing to know - is what you should avoid in SharePoint.
This comes only from real experience: when you read about those features on MSDN
or TechNet or fiddle with them in pet projects they look nice and appealing, but
then you start using them in real-world projects it often becomes a disaster.
My top5 of very popular SharePoint features which I would try to avoid at any
cost I want to share today.
1. SharePoint Mapped Folders
SharePoint Mapped Folders is most likely the very first feature you started to
use back in 2010 (and so did I). And before there was WSPBuilder, using the same
principle... And it was so handy, wasn't it? You merely create an ASP.Net web
page, put it into a mapped folder, and woo-hoo, it's inside SharePoint! You put
NO, I wouldn't use SharePoint Mapped Folders. I would try to avoid them as much
as possible. Because SharePoint is not ASP.Net! SharePoint has
it's own way of doing things, and although it perfectly allows you to stick back
to ASP.Net, and even supports that in a way, the other approach ("The SharePoint
Way"!!) brings much more benefits and gives the full SharePoint power into your
I would say, keeping back to ASP.Net in SharePoint is like keeping working on
Windows 98 virtual PC after installing Windows 7 on your computer :) Well, it
works, but it's just silly
you don't gain any benefits of new OS features :)
And yes, can't resist mentioning that in terms of new SharePoint 2013 Apps and
all this cloud business the mapped folders just don't exist at all... ;)
So, "no" to SharePoint Mapped Folders!
Surprisingly, XML definitions is another thing I would try to avoid. Well, short
XML things are perfectly fine but the "long" fellows like List Schemas, Ribbon
Customizations etc. are very hard to maintain, upgrade and troubleshoot. So if
you are engaged with a long-lasting projects with no direct access to
production, or you're creating an enterprise solution, this is a thing to
if you try to deploy a list (defined in XML) and there is already some other
list with same title, it will throw an exception and you can do absolutely
nothing to prevent or fix this! XML is not that flexible in SharePoint and this
is what you must always keep in mind.
So I would prefer replacing complex XML things with programmatic actions. Perfect example
is the Fluent Ribbon API opensource
project which does exactly that: replaces complex ribbon XML definitions with
easy to maintain and organize code definitions. Say, if you have a ribbon tab
with tens of controls inside, you can easily put each tab or control group in a
separate file or folder or whatever, organize it as you wish, generate it
dynamically and whatever, because it's just C#! Not
mentioning intellisense and on-fly validation and many more useful things... And
all those things are missing in XML.
The same holds true for content types, lists, libraries and many others. Don't
create them with XML. Use code. It's so much simpler. Write a lib for that if
you must. It will prove useful. And say "no" to long XMLs! :)
Custom Field Types
Custom fields types is again a thing to avoid. Such fields are readonly in
Datasheet view in 2010, and also don't quite work in Document Information Panel
in Office, and for example they
cannot be a target
for lookup fields and many other limitations.
Good foundation for creating custom field types is definitely a big loss and
something what SharePoint lacks, well at least 2010 version and before.
"Emulating" custom field types involves much XSLT and JS and don't work
everywhere either, but in SP2010 it was really much better approach than custom
There are some changes to this in SP2013 and I appreciate them greatly and hope
for the best, though so far I can't tell for sure that SP2013 custom field types
are good enough for production (unfortunately I just haven't been using them
long enough). Well, we will see.
Visual Studio Workflows
Visual Studio workflows always seemed to be an ugly duckling to me. I never
understood why people treat them as "advanced" version of SPD workflows. You
want to include code in SPD workflow? Write custom code activity, it is not a
problem at all... But Visual Studio workflows with their whimsical events and
lacking of automatic upgrade and all that...
Microsoft seems to finally admit this in SP2013, there Visual Studio Workflows
exist no longer (well, only in "2010 emulation mode").
5. InfoPath forms
InfoPath has great idea behind it: business users are able to customize the
forms. Great! Awesome! Not true in real life :(
InfoPath forms are really sophisticated. They have numerous bugs: e.g. it is
sometimes very hard to make a control one pixel higher than it is now and so on.
They lack modern elements: e.g. there is no tab control, and common method of
implementing tabs now (by copy-pasting views) stinks to high heaven... They're
difficult to migrate and deploy, and so on.
No, unfortunately, InfoPath is far from being Excel, especially when you design
InfoPath forms for SharePoint :( No, no to InfoPath.
SharePoint is vast and heavy and historical. SharePoint is flexible and rich and
efficient, in clever hands. SharePoint is awesome, if you know how to use it.
But you must know how to use it. And that's why you must know
how not to use it :) Consider this. And good luck with your