This blog post is aiming at developers that are looking for a solution to deploy SharePoint artifacts from code. Sure, you can do all of this by hand via the SharePoint user interface, but that is not repeatable.

In SharePoint 2007 the recommended solution was to use the feature framework. However, that had (and still has) one big disadvantage: It is hard to upgrade existing sites. FeatureUpgradeActions were introduced in SharePoint 2010, but it is still a manual job.

In 2016, the feature framework has been deprecated in favor of using CSOM / SSOM. I’m going to look at the framework we are using for most of our SharePoint projects to make this a breeze: SPMeta2.

What are your options to deploy SharePoint artifacts?

There are a couple of options to deploy your artifacts nowadays:

  • Use plain CSOM: Write all the code yourself. Maybe create your own framework.
  • Use Office Dev PNP (Patterns and Practices): Wrappers around the CSOM calls to make life easier. PNP is a lot more than deploying artifacts by the way.
  • SPMeta2: Another set of wrappers using a Fluent API around CSOM.

I have been deploying SharePoint artifacts using all of these options, and I’ve come to the conclusion that SPMeta2 is the best solution out there. It currently is a code-only solution, e.g. you will need to create a console application or Windows forms application to use it, and it is aiming at developers. There are plans to create a user interface to make it more appealing to users.

What I like the most, is the high level of code quality. This is I think the best code I have ever seen, in terms of unit tests and cleanliness. Really EVERYTHING is covered by unit tests.
There is a support Yammer network where you can ask questions or report bugs, and the SPMeta2 team usually replies within a day, which is awesome.

But the most important thing is of course the usability. The best thing about the framework is that you can run it over and over. Initially it will create all the artifacts, in subsequent runs it will update them. So, adding a site column is just a matter of adding the definition to the script. No need to worry about feature upgrade actions, feature versions, etc. SPMeta2 takes care of this.

Another important aspect is feature parity: With any wrapper there are areas that are not covered. SPMeta2 has done a great job in replicating the SP objects, to their code objects, and that way it is easy to implement something with SPMeta2 when you know how it works with CSOM. There are some edge cases that are only possible in CSOM, but in my experience that is about 1% of a deployment. So the feature parity is excellent.

Last but not least: You can easily switch between SharePoint versions. The SPMeta2 definitions don’t have any reference to either SSOM or CSOM, or a particular SharePoint version. So, if you decide that SSOM would work better, you only have to change a couple of lines of code. That’s it!

And now the other way around

Above assumes you start a new project, and you are defining everything from scratch. What if you have an existing site, and you want to create SPMeta2 artifacts based on the existing definitions to deploy to any other site? We have done this in the past, I’ve created Console applications that create C# code with SPMeta2 definitions using t4 templates, based on  an existing site.
SPMeta2 is working on a solution for this: SPMeta2 Reverse. This allows a developer to create the definitions, based on an existing site. And then it is possible to deploy it to any other site. Imagine the possibilities: You can provision a site collection that essentially is a template site. Business users can modify the template. And, you as a developer create a provider hosted add-in that uses SPMeta2 to deploy the site to any other new site.

This is however something that is currently in Alpha, and there are some bugs. I am aware that Dev PNP already has a working solution to do this, e.g. here.

What should you be using?

The development team here is very happy with SPMeta2 and we use it in all of our new projects. But it depends on your requirements what works best for you. E.g. if you need a sophisticated templating engine for self-service site creation, DevPNP is probably your best option.

But if you want to deploy new intranets, document management systems, or just any application to SharePoint on-premises or Office 365, I believe SPMeta2 is your best choice!

Disclaimer: Please keep in mind that it is my personal opinion and it’s NOT the opinion of any company I am working for.