SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

What is the best practice for creating a site column or content type in SharePoint 2013? Is it still recommended to use farm solutions? I was hoping we could do something with the new app model, but that appears to only allow site level features.

A little more background. Each developer has their own dev instance of SharePoint 2013. We also have a shared QA/UAT instance. And finally, there is the customer production environment.

I'm trying to get a Continuous Integration workflow setup, so that each developer commits their work to TFS, we can run an automated build that updates the QA/UAT instance. Once that is approved, I want to be able to give the customer a deployment package that they run in their environment.

I come from a ASP.NET background and I know how to do this there, but I'm unsure how to accomplish this with SharePoint.

share|improve this question
up vote 7 down vote accepted

Solution Packages - whether Farm or Sandbox - are still the way to go for deploying site columns and Content Types. With an "app", you can only deploy these artifacts to the app itself, not to the host SharePoint site (and I'm a little peeved with Microsoft for not making it more clear what you can and can't do in an app).

And yes, Sandbox solutions are deprecated technically in 2013, but they are not going anywhere, and they are still the only way to deploy code to SharePoint Online.

As far as your automated build is concerned, you should be able to accomplish what you are trying. One thing you should keep in mind though is that redeploying to UAT will necessitate deleting and re-creating your lists and libraries (and associated data).

share|improve this answer
You CAN provision Site Columns and Content Types via SharePoint apps using JSOM. Re. my answer below – Andrey May 3 '13 at 21:03

From SP2010 and forward we have not used solutions / features for this. Instead we use PowerShell to do this programmatically using server side API's.

By doing this we avoid "unghosting" the content types (as doing it declaratively does) and we also avoid having to deploy a package which include resetting IIS.

In SP2013 we continue doing this, but since we want to do this for our cloud solutions as well as on-premises solutions, we have converted our scripts to ClientSide Object Model (CSOM).

The one disadvantage of doing this is, that Microsoft unfortunately haven't supplied us with the possibility of deciding the Content Type ID as we can server side. This makes provisioning across platforms harder since we dont know the ID. It can be circumvented somewhat -for example in search you can use the CT name instead of the ID in queries.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.