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.
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.
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.
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.
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.
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.