FTC to CAM – Stop creating content types and site columns declaratively

[アーティクル]
11/06/2013

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.

Export the data out from the SharePoint
Modify the data by removing the dependency of full trust code
Ensure that you have corresponding CAM patterns in place
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! .

FAQ

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

Summary

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.

Comments

Anonymous
November 05, 2013
thanks Vesa - great information and summary to take care. sounds challenging but feasible
Anonymous
November 05, 2013
Use Overwrite="TRUE" in content type and field definitions and they will be provisoned directly to content database.
Anonymous
November 06, 2013
Thanks for the great write up and diagrams. Just to be clear, you are not suggesting a solution for client side code, only full trust solutions. Is that right?
Anonymous
November 06, 2013
The comment has been removed
Anonymous
November 06, 2013
Hi gandjustas, unfortunately that's not precisely true, which we can easily test by creating for example Sandbox solution which creates one content type using feature receiver code and one using xml with Override=True. When you retract this solution from the site collection, we will only leave the content type which was created using code intact, since that was provisioned to database and does not have dependencies on the xml files. The one site collection which had the override=True, is removed for the site collection content types.
Anonymous
November 06, 2013
Hi Tom, Yes. That’s the key point of the blog post. Use code based solution if you still do full trust code or farm solutions to make the future migration easier. Post is targeted mainly for the on-prem deployments to help on reducing complexity in future.
Anonymous
November 06, 2013
The comment has been removed
Anonymous
November 06, 2013
The comment has been removed
Anonymous
November 06, 2013
Sorry but SharePoint Online = no customisations. So limiting what you can do on Prem is dumb because you can't do the same thing or have the same applications with SPO.
Anonymous
November 06, 2013
Thanks for your comment Paul. I do strongly disagree that you can’t customize SharePoint Online, since already in 2010 version, many companies did have lot of customizations and solutions build on top of the SPO… Now with 2013, we have massive new opportunities with the App / CAM capabilities, especially if you start also using Windows Azure with your Office365. Approach is slightly different and there’s no one-to-one comparison for functionalities while comparing the models, but you can pretty much achieve the same end result from end user perspective also in MSO regardless of the needed customization. Due these new capabilities, most of the companies are seriously looking to reduce the needed hardware footprint on-premises and rather utilize the services from cloud. This blog post is telling some guidance how to avoid unnecessary costs related on the migration to the cloud if or when it will happen. Key point also is that while currently Office365 has some limitations compared to on-premises, these are being addressed pretty fast. This means that even though some capability could be blocking usage of the cloud now, situation can be completely different within one year and it would be pity if the on-premises deployment would be built in a way that it’s blocked to move anywhere else or due the approach which was taken, there’s significant additional costs. That would definitely not be what the executive sponsors for SharePoint projects are looking for and it can be difficult to explain that for your company CIO or whoever actually ultimately paid the deployment. It’s obviously up to you whether you follow this recommendation or not, but by following that you will decrease the long term costs during the life cycle of the deployment. This is classic discussion on whether to look benefits in short or long term.
Anonymous
November 06, 2013
What about translations of site columns and content types if you´re using the code approach. You can´t use resource files. What´s the solution here.
Anonymous
November 07, 2013
I would also be very interested in the multilanguage aproach when using CAM. Using CSOM you cannot set the titleresource property (SPUserResource), right? So i don't see a way for localization of fields, lists, contenttypes...
Anonymous
November 07, 2013
How about provisioning contenttypes, fields and lists using localization? - seems doing it by code is a no go - unless you use titleresource - and since language support can vary by web - it seems like an impossible thing to do - unless you run code to add new languages when they get added to a web ? In sandbox it seems localization of contenttypes is a no go ( XML-based provisioning)- unless iam mistaken, and code seems to be a no go in sandbox - so how would one go about that?
Anonymous
November 07, 2013
Hi Vesa, Removing User Solution deactivates all features and Content Types removed, even if created with Overwrite="TRUE". Removing Full Trust Solutions does not deactivate Site and Web features. Btw Overwrite="TRUE" or User Solution creates artefacts with code. Check code for Microsoft.SharePoint.SPElementDefinition derived classes with ILSpy.
Anonymous
November 07, 2013
Main problem of XML-based approach is not provisioning, it's retracting and feature deactivation. Some XML artifacts removed from SharePoint on deactivation, some become zombie (customized and lost link with parent definition on disk), some stays in place (lists). Next activation will skip existing lists, may revert customized files and provisions different set of artifacts (CTs and Fields). It's very hard to do idempotent deployment (after retracting) with XML definitions and without complete understanding of deployment process. Removing all deployed artifacts on retract is not an option, lists contains user data and CTs contains user customizations. Personally I recommend to block custom feature deactivation at all:

Make all features hidden.
Use ActivateOnDefault flag.
Use feature stapling.
Use web templates with predefined feature set.
Use Custom Action in sitesitecollection admin to activate feature. Really there are a few cases when features deactivated by users. In most cases features deactivated for upgrading by developers, but in 2010+ all upgrade can be done via FeatureUpgrade.

Anonymous
November 07, 2013
>> Feel free to use xml based deployment from VS2013 for app webs, since those are handled completely differently. It's handled by same code in Microsoft.SharePoint for any feature :) But removing app removes appweb completely and deployment process become idempotent by default.
Anonymous
November 08, 2013
Vesa, In my opinion, if you are building real Apps you should prefer procedural code over declarative code for provisioning. CAML only works in SharePoint hosted apps. It does not work for items provisioned to host webs. Procedural code is the only mechanism that works regardless of the provisioning target. There are some inconvenient holes in CSOM, such as the ability to specify content type IDs, but I have yet find myself unable to provision anything from Foundation (as opposed to Server) via the client API's in 2013. Keeping the provisioning code in the provider host in hybrid architectures makes it very easy to handle versioning and it has the significant advantage of being centrally controlled. You don't have to touch the app package to change things. Good article! --Doug
Anonymous
November 08, 2013
P.S. Having just read the rest of the comments I should add that in many cases and particularly the kinds of cases that makes Office 365 appealing, not being able to specify the content type ID is an annoyance (especially since ContentTypeCollection only has a method for GetById!) but not a crippling deficiency. I think the idea of hybrid sandbox + app solutions is an interesting idea and any excellent step-wise migration strategy to defer translating the CAML to code, but sandbox is really tough to maintain if the solution is widely deployed; this isn't a problem though if it is a one-off solution found in a single site. --Doug
Anonymous
November 08, 2013
Hi Jörg, Oliver and Lytjohan Thanks for your comments and good to see that at least the post caused some discussion, which was one of the intentions. Lack of proper multi-lingual support with CSOM or code based provisioning in general is definitely big gap, which currently unfortunately exists with CAM. This is definitely one of those pointers where you’d have to use classic models for now. This is one of those identified issues, which will be addressed but currently all localization in general is based on xml based resources, which would not be available with remote provisioning. If you do multi-lingual deployments or you’ll need to have multi-lingual site columns as an example, this is something to be definitely aware while planning the right approach. Like also mentioned in the post, these things are never black and white with SharePoint.
Anonymous
November 08, 2013
Hi Gandjustas Thanks first of all for sharing the good workaround for the challenge by using Overwrite=”True”. This is excellent information to be shared for the rest of the community, so that they can choose the right approach in their deployments as well. I completely agree that with SP the main challenge is around retracing and removing the dependencies of the xml or the pointers pointing things in disks, which do not exists. You do have good list of recommendations for the classic full trust code to avoid issues which will help in many of the scenarios by hiding the features and ensuring that end users can’t manually deactivate them and therefore causing additional challenges. In many of the those cases where we would hide the possibility for deactivation, we would however still cause dependencies between the content in database and in the file system, which would make the possible CAM migration more difficult. It might be that in your deployments, this will never happen and therefore this won’t be an issue, but my point was increase the awareness on the possible issues around CAM migration by showing one possible workaround for it. I should have been slightly more precise with my remark on the declarative element usage with App world. This is indeed definitely the same engine, but the deployment model for the content types is slightly different, since with App web, we are deploying content types to SPWeb scope, not to SPSite scope, which is the classic model. Also due the nature of the app web, this challenge which we have for normal web, is slightly different. I did have short chat with this one with Chaks, who’s working on the VS SP tools and based on that wanted to add some additional context. Sorry for not being more precise on that comment. Thanks again for your input on the comments.
Anonymous
November 08, 2013
Hi Doug, I’m all with you on the inconvenient holes and some lacking capabilities which are critical for the field. Many of these issues are already being addressed and will be released later to the field for enabling the common usage scenarios what we’ve been used to enable. We need to remember that the app or CAM world is only in v1 stage now and there will be lot of improvements arriving. Microsoft will be investing on this pattern also in the future, since already now it finally enables business solutions and other customizations to be running in the Office365 and by that it enables customer to seriously start reducing on-premises hardware footprint and to start using the capabilities in the cloud. CAM pattern is also great choice in the on-premises side, since it enables gradual updates and maintenance of the code without any downtime which would compromise the SharePoint service. Due also its nature of working kind of on the side of the SharePoint, it also degreases the needed quality and test processes. We are getting there, but gradually…
Anonymous
November 08, 2013
Vesa, You don't have to convince me. A majority of my working time has been apps for over a year now. I soft launched two apps, Instant Consulting Practice and Instant Legal Practice two months ago. You should check one of them out, I think you will be amazed by what can be done with a hybrid app. --Doug
Anonymous
November 08, 2013
Thanks Doug, at least I will check them out. New model is indeed pretty powerful and it will only get better after that time.
Anonymous
November 08, 2013
My main problem is that as far i understand and from what we have tested. There really is no "official" way of provisioning multi-lingual in full unless you do it on-premise as full trust scenario. Sandbox ( atleast vs 2012/13 ) - lacks a way of declaring resources names for contenttypes - needs to run code in feature activated to mitigate that. I am unsure if that is a limitation of vs.net ( OPC relationship as in app localization on host resources) - but since there is now a No-code directive using sandbox that would not be a good way to do it - even though we do it now - since there is no alternative ( in the cloud ) -- that was a problem i thought i'd put out there - been annoying me for a while :) but concerning localization and doing it non declaretively - you also have to consider that when you get access to titleresource at some point - there is still a need for additional support - since you can have a:

rootweb in some language ( maybe english )
subweb in some other language ( maybe german )
subweb gets alternative languages enabled ( default german - then enabled support for english + danish )
user enters site using a danish setup in browser / or chosen on users mysite - sharepoint will then go into danish mode - but since those alternative languages were not enabled when you setup title resource using code - its a no go. that means you would have to have some automation going on - to update localization support on types / fields / lists in each web everytime users add to the webs supported languages. its already something we struggle with today when we use code to provision lists / fields and types - because you can only set titleresource on languages supported in the web - at the point you set the it. ( all that is "given" to you - if you use declarative xml provisioning)

Anonymous
November 08, 2013
The comment has been removed
Anonymous
November 08, 2013
Sorry, little typo:

... statically checked...

Anonymous
November 22, 2013
Hi Vesa Thank you for the usefull explanation of a problem with declarative provisioning in SharePoint that happens during migration to a new SharePoint version (in farm solutions) One question please: what If during migration to a new SharePoint version we just place all the needed file system artefacts (like manifest.xml) to the right place (together with content database migration). Would it be enough to make content types working?
Anonymous
November 22, 2013
Hi Alexey, that would certainly help with the SharePoint major version upgrade, but the topic of the blog post was the transition from full trust code (farm solutions) to cloud app model (CAM), which requires that you don't have dependencies on your own customizations which are stored in server level.
Anonymous
November 22, 2013
Hi gandjustas, I completely understand your opinion on this, but there's actually much more benefits for the on-premises as well. If you move to CAM world, which is much more than just Apps, you can simplify your ALM processes and reduce the needed maintenance breaks with your deployments since you can update all of your customizations without impacting SharePoint services. This is pretty often seen by number one benefit by global enterprises, who are extremely excited on the new pattern. Second benefit is also the fact that we not only simplify the processes for ALM, but we also make the development more aligned with the other web based development models. You can certainly start using some of these also from our farm solutions, but in general by removing the feature framework dependency, we can more easily get additional people to SharePoint projects. You do need to still understand how SharePoint works, but from development perspective it's similar as other SaaS or private cloud services. We are now in transition stage and not all benefits are clear or well communicated our MS, but the change is evident... As a developer or architect, you can choose when you start moving to this direction as well, based on the skill sets. Change is however evident not only for cloud, but also for on-premises customers.
Anonymous
November 23, 2013
nice
Anonymous
November 28, 2013
Hi Vesa, For on-premises solutions are much simpler, than CAM.

Solutions are not requiring infrastructure. For CAM you should spin-up web servers and databases, make it failover and load-balanced, implement S2S and manage certificates. Then you need to provide somehow updates to web servers, databases and sharepoint artifacts simultaneously. You should hire army of DevOps to do this things.
Solutions are composable, Apps are not. You can build underlying services as FullTrust (foundation) and use them in Sandboxed solutions (concrete solutions). Sandboxed solutions are not impacting farm stability, like Apps. Full Trust provides power to developers, unlike Apps.
If you use classic web development model (ASP.NET MVC, EF, etc) you don't need SharePoint at all. But sharepoint contains lots of nice features that can't be integrated into app, like security model, search (searching for app data), built-in customizable UI, collaboration features.
Without knowledge of sharepoint it's senseless to get additional people to sharepoint projects. If we stick with Solutions model for on-premises it's better to learn how XML deployment works and use Visual Studio tools or extract XML artifacts from live sites. Btw it's good practice to start development with BrowserSharePoint Designer, then add simple code (js or server-side event receivers), then package it's all as featureweb template. It's not like classic web-development, but it's OK.

Anonymous
December 08, 2013
Hi gandjustas, I completely understand the input and the feedback related on messaging with the CAM model for on-premises. Personally I want to implement customizations which work both on-premises and in cloud, so that they can be used cross the environments, but I completely understand other opinions as well. We do have many global customers moving now from FTC to CAM also in on-premises, since this is the roadmap of the SharePoint. Transition will happen gradually, but it's also evident for on-premises due the advantages it brings on that side as well which varies from operational cost impact to the code re-use. Here's few pointers.

Reduction of needed infrastructure for SharePoint due simplified ALM processes – CAM is isolated, no need for 3 different test environments. You do need to host the code in .NET environment still though
Development can happen from any Win lap top, no need to have 32 GB memory for each developer also with private cloud – massive cost reduction
No service breaks for the SP services when code is upgraded – classic complaint... service breaks are isolated to provider hosted apps
Minimal cost impact while upgrading to next major version – massive deal with more frequent releases. This depends heavily on type of customizations you do
Write once, it will work in any platform or cloud provider – customers can choose where you’re intranet is hosted… code will adapt. Big deal for executives
Possible issues are isolated on specific capabilities – SharePoint services are not impacted, just specific functionalities
Customer can choose how and when customizations are upgraded – customizations don’t block access to latest and greatest SP version Obviously many of the above things are debatable, but these are commonly the reasons why even on-prem customers are moving to CAM world. We are all entitled to our own opinions and to be honest, I also love writing FTC code. I've been doing that as daily job since we started implementing stuff on top of the SharePoint 2007. At the same time I have now made the decision to jump on the new train to keep up with the product roadmap.

Anonymous
December 10, 2013

With user solutions (CAML+JS+small amount of server-side code) you don't need 3 different test environments. You can test solution in separate sitecollection and have no service breaks during upgrade, no blocks to upgrade to next major version.
Development provider-hosted HighTrust apps requires SharePoint for debugging workflows and event receivers. SharePoint-hosted apps are almost useless.
Write once - run everywhere is nonsence for onprem. All arguments are weak for current situation when most customers runs onprem sharepoint. I know customers moving from FTC to CAM because Microsoft pushes them. It's not their decision. Microsoft "sells" fear of FTC to everybody, but real problems not with FTC itself, it's because bad code. I'll bet HighTrust apps with bad code will suffer from same problems.

Anonymous
December 16, 2013
The comment has been removed
Anonymous
February 13, 2014
Hi Vesa Can you please direct me to a guideline about customizing SharePoint online? If I want to deploy : •Site Columns •Content Types •Page Layouts •Mater Pages •CSS •JavaScript •.webpart or .dwp files to SharePoint Online.
Anonymous
February 13, 2014
Hi Uday, there's lot of guidance on those topics in the MSDN and easiest way to find them is simply to use Bing or Google. You can also find examples of those scenarios from the examples what I've released in this blog. In short the approach would be following for each of them.

Site Columns - you can create these by using CSOM
Content Types - You can create these using CSOM as well, but if you need to use specific GUIDs, you'll have to use Sandbox solutions for now. Setting ID for content types will be supported soon also in CSOM
Page layouts, master pages, css, javascript, web part files. These are classic module elements and you can easily get them to proper location using FileCreationInformation object. This is demonstrated in many of the examples in this blog and elsewhere.

Anonymous
April 19, 2014
Regardless of Microsoft trying to sell fear to FTC, I have been convinced and I am fully convinced of the power of apps, and how easy its it. I have seen all SP2012 and SP2014 videos about apps, I have read all office ams code and I have tried most of them my self. I have found almost a map one to one to almost all FTC problems, even timer jobs, the only one missing is custom field types. Said that, I believe that Apps is the way to go, we can handle all our provisoning using RERs in the App Installed and Uninstalled, and handle upgrading in the Upgrading event. We require more hardware and database to isolate the apps, yes, but the positive effects of this are way too much better to ignore them, the biggest benefit as Vesa said for me, its no downtime easier upgrades, and faster ALM processes. Ignoring that is nosene
Anonymous
April 22, 2014
Hi Luis, thanks for the comment. Personally I'm finally seeing that we don't really need to sell Apps anymore that much, since the benefits are greater than the overhead to transforming. It's never been about the fear of FTC, rather on the advantages of the Apps. We can all still use FTC, if needed, but product and Office365 roadmap is build on top of the app models, so each of us developers can decided which way we want to go. Thanks indeed for the reinsuring comment on your side.
Anonymous
June 24, 2014
Hi Vesa, We are evaluating options to move our O365(D) customer's FTC code base to CAM Model. They have many Content Types created using Feature Xmls deployed to Content Hub. As you mentioned in your post, if I de-activate the feature, the Content Types get removed. Since with SharePoint 2013 SP1, there is a capability to create Content Types with specific IDs, would this be an option to migrate the CTs to CAM model? De-activate the FTC Feature to remove the CTs from the CT Hub. Using CSOM create the CTs with the same IDs. Do you see a challenge? Thanks, Ravi
Anonymous
July 01, 2014
Hi Ravi, this is classic challenge of the app model transition and actually exactly the scenario why I wrote this blog post. To be honest, blog post learnings are coming from one of the Office365 Dedicated customers as well. Right now MSO engineering and product group are working on getting the transition story for the content types. If you customer in Dedicated platform, we would recommend them to join on the JDP program which is supporting Dedicated customer on their transition to the new app model capabilities. Through this program we provide immediate insights on getting these kind of issues resolved before we can share the details for the field.
Anonymous
July 03, 2014
I'm also interested in getting some guidance/patterns scenario similar to the one mentioned by Ravi. That is migrating existing Content Types and Site Columns created using Feature XMLs deployed to the content type hub or activated on all site collections to a solution that creates them using CSOM. If it can be done without creating some temporary content types to be used for migration, that much better.
Anonymous
July 08, 2014
One those posts rare entries that are SUPER valuable in real scenarios. Thank you Vesa and Gandjustas for the little trick on Overwrite=True; saved me a lot of headaches during a 07 to 13 migration with... yes.. TONS of declarative xml content types.
Anonymous
August 18, 2014
The comment has been removed
Anonymous
August 18, 2014
Hi Shriram, This would indicate that you are using 16 version of the CSOM library within the on-premises, which is unfortunately not supported. Like mentioned in the blog post related on this one, this multi-lingual support for Resource entries is not currently available with on-premises. blogs.msdn.com/.../office365-multilingual-content-types-site-columns-and-site-other-elements.aspx I completely understand that this is not the message you were looking, but that's just the current status.
Anonymous
September 08, 2014
Thanks for your answer Vesa! So does that mean, For SP OnPremise, we at all should not use 16 client version with provisioining code? Will it have any other issues as well? Actually we wanted to keep the same client version to work on both OnPremise and Online. But if 16 version is not supported for OnPremises, then we will have to use two different versions of client dll. That is 15 client version for OnPremise and 16 client version for SP Online. Please let me know about your thoughts on the same. Thanks!
Anonymous
September 08, 2014
Hi Shriram, challenge with the 16 version CSOM is that it's exposing capabilities are not in on-premises. In general 15 version is for on-prem and 16 version is for online.
Anonymous
September 09, 2014
Thanks for the clarification Vesa!
Anonymous
March 11, 2015
Hi Vesa, MS has made lot of changes to CSOM now.. considering the improvements.. whats the official recommendation for deploying content types, site columns to office 365? recommended to use sandbox solutions or through CSOM? I presume that for the branding artifacts the preferred approach is design packages.. Looking for your comment.
Anonymous
March 19, 2015
Hi CG, Recommendation is to avoid sandbox solutions and to use CSOM to create needed objects. See following resources for the Office 365 recommendation:

次の方法で共有