Really… just don’t use element xml files to provision content types or site columns in your full trust / farm solutions. This relates on the full trust code (FTC) to cloud application model (CAM) model discussion but is also relevant if there would not be any short term plans moving to cloud and you are continuing to use full trust solution. I know that we’ve been teaching how to use feature framework and element files to provision site column and content types to site collections and it has been viable option for long time. It does however have huge impact on the future upgrade / migration requirements and costs. You could almost state that using declarative pattern for content types is as evil as using still custom site definitions (no no no no no).

Let me explain before you judge this recommendation. This came as a surprise to me as well and was definitely as surprised as some as you might be, since even though for many automation tasks I’ve been using code, for content types and site columns, I’ve just grown used to use xml since the birth of feature framework.

Update: Good feedback from Chaks’, so that message is not wrongly taken. This recommendation is for full trust solution / farm solutions and is not valid for app web. Feel free to use xml based deployment from VS2013 for app webs, since those are handled completely differently. Also Chris had really good pointers related on the sandbox solution recommendation, which is slightly clarified more in the post comments.

Update on 13th of Nov: Based on lot of questions coming in with this one, wanted to add few notes. “I always thought that MS is recommending using xml files for content types and site columns” – “Does this mean that recommendation has been changed?”. Yes and no. Things with SharePoint are not black and white, since there’s always multiple different factors to take into account when you design your customizations.

This blog post was created based on findings related on needed actions with xml based provisioning of content types and site columns when transitioning to CAM model. These migration projects could be challenging, so it’s at least good to know the impact of chosen pattern. Many times you really don’t have even alternatives, since you can’t create multilingual site columns or content types with code, like pointed out in the comments. Secondary objective was to create discussion on the topic, so that we understand the impact and possibly find alternative approaches for our objectives with the shared knowledge of the community.

Understand the impact and why certain additional steps might be required in future, is the important thing. Do you choose to use xml or code is a secondary question, since things are NOT black and white.

Challenge with xml based provisioning

Notice that as being consultant, I used the term challenge… not “issue”, which might have been better word…. anyway, back to the topic...

Below picture is explaining the classic dependencies between elements when we create content types and site columns using element xml files. You will be deploying full trust solution, which has the feature with element xml files. These xml files basically explain for the SharePoint what kind of structures will be created to database when the feature is activated. Challenge is however that this operation is NOT only provisioning time, which means that if you retract the solution from the farm, these content types will be also removed from the site collections where they were provisioned. Content created using the content types and site columns will remain in the site collection, but you can’t create new content based on these elements and you would run into issues sooner or later with existing content as well when modifying it due lack of the needed definitions.

Notice that even though we used full trust solution as the example scenario, this same challenge exists with the sandbox solutions, even thought the location of the files is slightly different. When you retract sandbox solution from the site collection, also provisioned content types are gone.


What’s wrong with that?

Let’s move back on the actual topic of FTC to CAM. As part of the roadmap of SharePoint we are gradually moving from FTC to CAM patterns. We have multiple enterprise customers already taking this leap and more are aligning also their on-premises deployments with the product roadmap. For new deployments this is not a difficult move, but for old customers who would like to convert their existing SharePoint solutions to this CAM world, this will be much harder. Technically we can achieve many of the needed capabilities, but one big challenge is the how to covert existing web applications build using old customization patters to the new CAM world.

One of the key principles of the new CAM world is that build our customizations in away that they will work regardless of the deployment platform, meaning that they will work regardless of the solution to be hosted in the on-premises or for example in the Office365. This provides customers choice to use the most cost efficient and flexible platform based on their business needs, not based on how things are build. To be able to transition to this model, we’ll need to get rid of the full trust code dependency and that’s when it get’s tricky if you have created content types and site columns using element xml files.

If we have used the old pattern and we’d like to convert existing site collections to new CAM based solutions, our only option is full scale migration, since you can’t get rid of the solution package dependency using any supported means. This means significant additional costs and need for establishing separate migration project for removing the solution package dependency on the content types and site columns. These elements are so fundamental elements in the SharePoint, that there’s really no easy way out of the dependency otherwise.

Here’s the simplified process for migrating away from the solution package dependency.

  1. Export the data out from the SharePoint
  2. Modify the data by removing the dependency of full trust code
  3. Ensure that you have corresponding CAM patterns in place
  4. Import the data back to SharePoint with updated definitions

Notice that this can be extremely difficult, so please be aware of the needed work and costs on this process. We can however avoid this painful process by thinking beforehand how we create our full trust code solutions.

Workaround for the challenge

Work around is actually pretty simple, but does require some additional code to stream line the process. Following picture is explaining this in high level. Essentially we can avoid this issue by using feature receivers and code to create the necessary site columns and content types to site collections when feature is activated. This will mean that solution package (wsp) will have dependency on the feature framework feature, but since content types are created using code, we have only provisioning time connection from the feature to created content types.


So if you have created the content types and site columns without element xml files using simply code from feature receivers, you can retract the solution package from the farm without impacting the site collections. Obviously there could be some other dependencies like ghosted module files, but those can be fixed on fly. Challenge with the content types and site columns is that you can’t remove the dependency after they’ve been created using element xml files.

So if you still create full trust solutions, please ensure that you don’t create content types and site columns using element xml files. Just don’t – it will bite you!.


Few frequently asked questions on this topic to further explains the reasoning.

  • So are you saying that we should not use the xml wizards in Visual Studio 2012/2013 for creating the site columns and content types?
    • Yes. These are really good helpful wizards, but if you want to minimize the future maintenance and upgrade challenges, you should not be creating site columns and content types using element xml files
  • What about the other feature framework elements, like module element?
    • Module element usage slightly depends on the model related on ghosting or un-ghosting. If you have deployed your artefacts using ghosted model and you remove the solution package from the farm, there will be a pointer in the database to file in file system, which doesn't exists and this can cause catastrophic issues. You can however handle this during your FTC to CAM preparations by mvoign the file to be un-ghosted. This way the file will remain in database when solution package is remove and functionality won’t be impacted
    • Classically in full trust code deployment model we have promoted ghosted files for the sake that you can more easily update all sites and site collections, since they point to single file in disk. This pattern however has implications on the possible future transition to CAM pattern like explained here.
  • I’m already fully in CAM side, but can’t find a pattern to create content types using specific identifiers, how to proceed?
    • This is actually slightly off the topic, but there is currently indeed limitation in the client side operations that you can create new content types using CSOM, but you can’t assign identifier for them, which will cause the content type IDs to be different cross site collections. You can use either content type hub or sandbox solutions to ensure that IDs match matched cross site collections, but both of these options are also limited and do not work that well in cross-tenant, cross-farm or hybrid scenarios
    • This limitation will be addressed, but there’s no public schedule for it


There’s no such things as best practices with SharePoint and recommendations are never black and white (could be up to 50 shades of grey), but I’d strongly suggest to consider the pattern to create content types and site columns using code to help on future upgrade and migration projects aligning deployments towards SharePoint roadmap. In short term you might be still tempted to use declarative approaches for content types and site columns, but at least after this post, you should know the long term impact of that pattern also from work or cost perspective.

You’ve been warned, but it’s obviously up to you how you write your customizations.