This post is migrated from previous hosting provider. There are still some issues with old posts. Please make a comment on this post with any issues.

Avoiding Xml Based SharePoint Features - Use The API Way

Tags: SharePoint

Developing solutions and features for SharePoint is a nightmare for all beginners, and even for the experienced SharePoint developers. If you ever have had the opportunity to create a SharePoint solution you most probably have had to make a lot of hacking in a bunch of XML files, just to build a simple feature. This is the way you have to do it, and the way taught by tutors and Microsoft, when using it with Visual Studio and no add-ins. This is the way it was, and has been, for most of us SharePoint programmers since the beta releases of SharePoint version 3.

Nowadays you have several tools that help you out; such as Visual Studio Extensions for WSS, WSPBuilder, STSDev and more. Some have a user interface that helps you a lot; such as VSeWSS and SPVisualDev and some does not help much there; such as STSDev. But whatever tool you use you will find that you are digging yourself deep into hacking those Xml files. Unfortunately the documentation is quite poor, but we have the fantastic SharePoint bloggers and MVPs that made their code and samples available through Google, sorry Bing.

Lots of XML

For example when you have a site and you would like to create a custom list, you will have to define a Content Type, a list schema, a list template and a list instance and then you have a feature manifest and a solution manifest - that counts to at least five different XML files and a few different schemas. This is an awful amount of job in the beginning and I think in some cases it's a waste of time, especially if it's a custom list that only will be used once. Then we have the thing when we want to update the list or content type when it's deployed...a whole lotta XML in combination with compiled code (for example when updating Content Types)!

I have in my recent projects abandoned the XML way (declarative/CAML) in favor of the The API way (Object Model).

The API Way

Almost everything that these XML files can do can be done using compiled .NET code and utilizing the SharePoint API's. Take the example above - those XML files can be replaced with a few lines of C# code. Create a Content Type, create a List, add a Content Type to the List. There are still few XML files left; the feature and solution manifests; but those two are easy to handle.

All you have to do is put this initialization and creation code in the Feature Receivers of the Features.

Upgrading and developing these features using the API way are also very easy and straightforward. I think it also fits better into a TDD kind of development way. If you have a list that is created through the Feature Receiver and you find that you need to add a field to that list, I just de-activates and activates that feature. This is done by a set of extension I use to create fields if they don't exist, in Lists or Content Types.

API way - Pros

Using the API way has several benefits:

  • As a beginner, but experienced .NET developer, it might be easier to start working with the SharePoint API
  • Mistakes are easier discovered:
    • You have to deploy and test your feature to find small mistakes in the XML
    • Some errors are detected during compilation phases
  • Debugging - yea try that with XML based features!
  • Upgrading experience is far much better (de-activate and activate)
  • Development time is most often faster, just re-register the assembly
  • Easy to staple the feature, and it's receiver, to Site Defintions
  • Testing, and TDD, is possible even outside of the SharePoint scope

API way - Cons

Of course there are cons of using the API way. First of all there are some things that you can't do

  • Create List Templates - for reusable lists, i.e. lists available for the end-user to create
  • Create Site Definitions
  • Create Custom Actions
  • Configure Delegate Controls

The cons with the API way are for example:

  • Requires installation of assemblies in the GAC
    • This is in many installations prohibited due to the fact that it requires that you run in full trust.
  • I find it easier in some situations to re-use configurations created in XML files
  • When using XML definitions you can specify ID's of Content Types etc which are required in many situations, for example when you are re-using your Content Type in many farms or Site Collections.
  • Requires that you really understand how the provisioning works in SharePoint
  • Requires that you take care of the clean-up when deactivating

Most pros and cons are of course a personal consideration, but as I said, I almost every time nowadays use the API way for my features.

How do you develop your Features, Lists and Content Types?

Basically I try to have a clean and simple Site Definition and then staple my features and it's receivers onto that Site Definition. It comes down to very little XML and some compiled code - very maintainable.

No Comments

  • Oskar Austegard said

    I have tried going all-out XML, even customizing view presentation-caml (yuck), and became quite well versed in list schema.xml writing in the process. And I have tried going all-out API. Liked it a LOT better, but there are areas where you still need the XML, unfortunately, like custom fields, etc... Here's to a better experience in SP 14

  • Daniel Karlsson said

    One problem with creating lists or content using a feature receiver is that it might be duplicated if you are in a farm or especially if you are using content deployment. This is due to the fact that the feature will be activated everywhere and as a developer you really need to take this into account.

  • Andy Burns said

    It's funny, we were talking about this in the office yesterday. The conclusion we came to was that the 'All API' way has a lot of benefits. For complex stuff, I seem to end up using the API anyway. That said, most of my features do still use XML as much as possible. I think that this is largely down to the tools that help generate the XML. Without that, it would be a no-brainer - API every time.

  • Wictor said

    Agreed, using the declarative way will help you avoid those situations, due to its limitations. As I said clean-up is something you have to take care of and touches the issue you have if you already have your lists/sites or whatever you are provisioning.

  • Wictor said

    Yup there are a lot of benefits of both ways - you have to know what your goal is. This post was written to force some comments. I still use the XML way when you have to reuse functionality or deploy staging environments for instance. Another downside with the declarative is that you are quite limited in what you can do. A good example where you have to use the API in combination with XML is when you have a site definition and are deploying it together with highly customized web part pages - then you're only option is feature receivers. All in all, it's a matter of taste and skill.

  • The Daily Reviewer said

    Hi! Congratulations! Your readers have submitted and voted for your blog at The Daily Reviewer. We compiled an exclusive list of the Top 100 sharepoint Blogs, and we are glad to let you know that your blog was included! You can see it at You can claim your Top 100 Blogs Award here : P.S. This is a one-time notice to let you know your blog was included in one of our Top 100 Blog categories. You might get notices if you are listed in two or more categories. P.P.S. If for some reason you want your blog removed from our list, just send an email to with the subject line "REMOVE" and the link to your blog in the body of the message. Cheers! Angelina Mizaki Selection Committee President The Daily Reviewer

  • Henrik Andersson said

    Did my first API-way project recently and I must say it felt better and more robust than fiddling around with the XML files. Together with Patterns and Practices for SharePoint I now got a project which is easier to test and re-use in other projects.

Comments have been disabled for this content.

About Wictor...

Wictor Wilén is the Nordic Digital Workplace Lead working at Avanade. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for seven consecutive years.

And a word from our sponsors...