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.