SAF is released!

At Last! Finally, we have released the SharePoint Action Framework (SAF) on CodePlex!! Please take a look here : .

Now that I can take a minute, I just wanted to spend a bit of time detailing why we have spent the best part of 18 months (with lots of late nights!) building it. Here’s a FAQ to give you some answers:

If you are developing with SharePoint, do you suffer from any of these ?

  • Lots of Defects caused by differences in SharePoint Farms. – e.g. “It works on Integration, but not on QA!” .
  • Your Development team find it time consuming telling your Release team what to do for each release. “How hard can it be to put 5 columns in a Content Type?”
  • You have release documents (notepad, word, etc) that don’t contain enough information on how to deploy, or they always miss things and are extremely time consuming to create. “By heck surely there must be a better way of telling the Operations team what I need doing ?”
  • Deployments to key farms are always late and very stressful. “I hope we don’t get a release like that again, I didn’t finish till 2am”
  • Developers find it hard to do daily builds as SharePoint Config is not part of the daily build process.
  • It’s hard to reproduce what you have on one farm to another.
  • Changes to Testing and Live Farms never seem to be applied to the Development Farm.
  • You have lots of Features doing “similar” things, but not many are reusable.

Why we built SAF (“Techy” answer)?

Put simply, SAF allows you to author SharePoint configuration changes so that you can install (“do”) or uninstall (“undo”) them on your Dev, Test and Live Farms. These changes are generally authored inside Visual Studio and mastered in your favourite Source Control system, (such as TFS). As the SAF engine, to run these changes is lightweight, (written in C#), its also pretty simple to use via :

  • SharePoint Feature
  • STSAdm
  • .Net code
  • Web Service – (Coming soon)
  • MSBuild Task – (Coming soon)

Isn’t CAML used for this ?

Yes, and no. We quickly found that CAML for deploying artefacts like “Content Types” and “Site Columns”, is just the ticket for new builds, but as soon as you want to maintain them, the story isn’t good. Where we found it necessary, we replaced the processing of some standard CAML with a SAF Action. (see “EnsureSiteColumn” and “EnsureSiteContentType“).

In addition to this, CAML only takes you part of the way through your journey. As soon as you want to do anything that it doesn’t support such as Importing Content into List Items, Lists or Webs, or setting a particular Web Property you will have to do it using custom code. This custom code then needs as much effort given to development and testing as your main application code, which is often overlooked on Projects.

We currently write Feature Receiver code to “package” config, do I need SAF?

If I was forced to say in 1 word “Why use SAF?” it would be “reuse”. If I had to do it in 2 more words it would be, “reuse” and “reuse”. SAF was built to allow you to reuse via Macros. (“Macros” are lots of Actions that you want to run sequentially). Some of you may have extremely well written “Feature Receiver” libraries, that allow some form of reuse. With SAF, we are attempting to take away the need for writing any code in Feature Receivers (as we have done it for you) and also at the same time allowing your System Engineers to get involved in creating them by using good old XML.

What are the alternatives to SAF?

The team building SAF have worked on a number of SharePoint applications that rely on methods such as custom console applications right through to 40+ page Word documents to recreate configuration amendments in each environment. (This quickly becomes unmanageable, error-prone, time-consuming and very quickly results in PM’s saying things like “Why do we always get these problems at deployment time?!?”).

Is it easy to learn?

We certainly hope so! If you look at the source code on Codeplex, there’s a lot there and I can understand why you may be scared. Don’t worry, you will never need to know most of it, it’s just there to make your life easier. If you are thinking of using SAF, please take 10 minutes to look into the “Sample Features” project, or look at the “Quick Start” on our Codeplex page.

I now understand that “Macros” and “Actions” are the building blocks to package my SharePoint config, so can I write a “Merge Staff lists” Macro for my company ?

Yes, most definitely! With changes that Hugo has made recently, this can be as simple as implementing one method in C# (or VB.Net). Of course, if your Macro is something that the community can all enjoy we will add it to the core SAF library!

Does it work on MOSS or WSS?

We have spent a lot of time dividing the libraries and Actions into MOSS or WSS. You can clearly see when using SAF Actions what the reliance is, so it’s pretty obvious!

Why have you guys done this ?

SAF started as a result of feeling the “pain” several times over on our projects. It’s since been though one major re-write (mainly to leverage Spring.Net) and now we are finally coming to the stage where we hope the community will embrace it.

Where’s all the documentation ?

Truthfully, we are working on it – at the moment there simple aren’t enough hours in the night ;)! Quite a lot of the API is documented and we do have a “quick start” on Codeplex which should take you a long way to understanding it. However, we are going to document all of our Actions, in the next 2 weeks, so will release as soon as we have a decent chunk ready!