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


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.

image

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.

image

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 (49)

  1. thanks Vesa – great information and summary to take care. sounds challenging but feasible

  2. gandjustas says:

    Use Overwrite="TRUE" in content type and field definitions and they will be provisoned directly to content database.

  3. TomResing says:

    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?

  4. Chris OBrien [MVP] says:

    Hi Vesa,

    Very interesting, and it's great to see guidance coming from trusted Microsoft sources on topics like this.

    However, I'm struggling to see what the issue is with XML-based provisioning *in sandboxed solutions*. For full-trust solutions of course, there are *lots* of issues (given that provisioning to the filesystem occurs) – it's clear to see where upgrade pain can come from here. But for sandboxed solutions, if we're saying that Microsoft may decide that some previously-recommended declarative techniques (with site collection scope) are not upgradable going forward, then I think that would be a big deal. And surely Office 365 has *many* such solutions running in tenancies right now?

    In terms of the dependency on artifacts in the WSP, is this such a big deal in a sandboxed WSP? Sure, the solution will break if the WSP is removed – but it also would if I removed a file that was provisioned by a Module, or took any number of similar actions 🙂 Given the architecture of SharePoint, solutions will always have an element of "site infrastructure artifacts" required for them to run.

    If the scenario involves a cross-tenant, cross-farm or hybrid situation, then as you say there are issues with running sandbox WSPs (e.g. reuse/operational overhead) – but often it's still a better trade-off than other options I feel, and whilst I might be missing something, I'm not sure code-based provisioning solves those particular problems.

    Finally, the recommendation of using code-based provisioning (e.g. JSOM/CSOM) does seem contrary to guidance from Richard diZerega's "SharePoint sandbox isn't dead…UserCode is" post (blogs.msdn.com/…/sharepoint-sandbox-isn-t-dead-usercode-is.aspx), where he says:

    "However, declarative solutions are very much still in play and widely used internally by SharePoint (ex: Web Templates and Design Manager).  A declarative .wsp package (one containing no assemblies) is a powerful way to provision elements into the host web.  So don't be afraid to leverage the solutions gallery as long as your .wsp packages don't contain code."

    Any thoughts on this? Or when MSDN documentation might catch up with the latest thinking?

    Thanks again for your recent posts.

    Chris O'Brien.

  5. Vesa Juvonen says:

    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.

  6. Vesa Juvonen says:

    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.

  7. Vesa Juvonen says:

    Hi Chris,

    I completely get your point and reason for the comment. First things first: MSDN blogs from individual consultants or architects are not official statements from the Microsoft. These blogs are indeed from Microsoft employees, but either me or Richard are actually working for product group directly, which means that we don’t represent the final official statement from product group (PG) and should not be referenced as being that, unless explicitly mentioned in the blog post. We do work for Microsoft, but that doesn’t mean that all what we write in our blogs have been validated or approved by SharePoint PG.

    That’s being said, both of us do work closely with PG on many CAM related topics, so stories are quite often initiated from the discussions or other programs close to PG and deprecation of code behind Sandbox solutions is something which we’ve been covering openly in our internal Ignite trainings, so that’s definitely correct statement and it would be great if the MSDN would be finally updated accordingly. Reasons for the delays in MSDN or TechNet is completely other topic, which I won’t go into.

    This blog post did concentrate more on the on-premises full trust code or farm solution recommendations to avoid unnecessary work related on future transition to CAM / App world. My concentration was mainly on making the future transition as smooth and cost efficient as possible, by providing insights from the enterprise projects we currently work.

    For Office365, sandbox solutions is currently the only way to deploy content types using specific ID’s, which is massive limitation, like mentioned in the blog post as well. This is being addressed, but at the same time using declarative sandbox solutions will cause the similar challenge in Office365 or in on-premises like the farm solutions if you will remove the package. I completely agree that module element can cause similar ghosting challenge, but that can be actually usually fixed also afterwards by deploying corresponding un-ghosted module file to proper location.

    In optimal world, if we would use remote provisioning techniques to push the content types to site columns using code, we could ensure that content types do not have any dependencies on WSP packages and we could ensure that they are create using specific GUIDs.

    Like you know, currently we do not however have this capability in CSOM, which makes us fall into sandbox solutions in the Office365, but there’s clear value on doing so for on-premises.

    This is propably the longest comment in my blog ever, but long story short… I agree that with Office365, we would need to resort to sandbox solution usage and there’s really no other options. Key objective was however to raise awareness of the possible unseen challenge and hopefully positively impact at least few future deployments.

    “There’s no such things as best practices with SharePoint and recommendations are never black and white”

  8. Hi Vesa,

    very interesting post and somehow "sad" that the, in my personal opinion more standardized, declarative approach will be discouraged for these migration reasons. Feels like I lost my fight against the windmills (==.NET developers who always like to do it programmatically) is lost 😉

    I understand the challenges of course and the reasoning behind your recommendation.

    Still it feels like the application lifecycle management (which is in SharePoint … let's say… improvable) will get harder and harder in the future.

    How do I assure that a change to my solution is actually available everywhere where it is used.

    Sure, through code I could run upgrade actions on each site and when using the content type hub this will work fine for the described case. But I suppose moving away from declarative code for ContentTypes and Site Columns is just the beginning.

    Considering the recommendation of un-ghosting files provisioned through modules will remove the capabilities of centrally updating these files without iterating through all of the site collections and hoping nothing goes wrong along the way.

    Looking at SPO this scenario looks even more scaring at the moment…

    I am really hoping that Microsoft comes up with solutions and guidance for that pretty soon.

    Thanks for sharing your thoughts!

    Matthias

  9. Paul says:

    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.

  10. Vesa Juvonen says:

    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.

  11. Jörg Spilker says:

    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.

  12. Oliver Zeiser says:

    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…

  13. Ole Lytjohan says:

    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?

  14. gandjustas says:

    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.

  15. gandjustas says:

    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:

    1) Make all features hidden.

    2) Use ActivateOnDefault flag.

    3) Use feature stapling.

    4) Use web templates with predefined feature set.

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

  16. gandjustas says:

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

  17. Doug Ware says:

    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

  18. Doug Ware says:

    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

  19. Vesa Juvonen says:

    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.

  20. Vesa Juvonen says:

    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.

  21. Vesa Juvonen says:

    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…

  22. Doug Ware says:

    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

  23. Vesa Juvonen says:

    Thanks Doug,

    at least I will check them out. New model is indeed pretty powerful and it will only get better after that time.

  24. Ole Lytjohan says:

    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)

  25. gandjustas says:

    For onprem scenario apps almost useless.

    SharePoint hosed are much more limited than sandboxed solutions. Appweb is not suitable for user data, crating lists in host web requires lots of code and high permissions, which reduces app isolation.

    Provider hosted app requires managing web servers and databases, which increases licensing and administration pressure.

    There are two scenarios for app for onprem:

    1) Small and simple functionality, requires external data. Like displaying weather for user location. Built as SharePoint-hosted.

    2) Integration existing apps to SharePoint.

    But none of them requires deployment artifacts to host web.

    For all other workloads if preferable to build with solutions, not apps.

    Code-based provisioning is bad choice for solutions:

    1) it's much more verbose and much more limited than xml-based

    2) it's can't be statically cached for correctness (look at http://spcaf.com and spcafcontrib.codeplex.com)

    3) it's very sensitive to partial failure scenario

    4) it's should be written by hands, not wizards or importing existing artifacts (I do importing almost always)

    My opinion – Microsoft should fix XML deployment, make it more transparent, controllable and documented, and enable xml-based deployment to host web for apps. It will simplify migration of solutions to apps (cloud) much more than pushing developers to do code-based provisioning.

  26. gandjustas says:

    Sorry, little typo:

    2) … statically checked…

  27. Alexey says:

    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?

  28. Vesa Juvonen says:

    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.

  29. Vesa Juvonen says:

    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.

  30. gandjustas says:

    Hi Vesa,

    For on-premises solutions are much simpler, than CAM.

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

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

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

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

  31. Vesa Juvonen says:

    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.

  32. gandjustas says:

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

  33. Vesa Juvonen says:

    Thanks Gandjustas for your feedback.

    Like mentioned in this blog post already earlier, these things are never black and white. My intention for this blog post was to share something what we have now encountered with multiple enterprise customers who are moving to the CAM world since they see great advancements on that side. If we can avoid solutions, which will cause significant costs in future, it should be done… or at least we should understand the impact of our design, if we don’t do so. There’s really no right or wrong in solution architecture design, key point is to make knowingly decisions impacting short and long term costs.

    Obviously it’s not one size fits all and there will be lot of full trust code deployments still done for the on-premises as well. I still want to share the findings and practices to avoid possible future costs with the field based on our findings.

    Many customers are indeed still running SharePoint in on-premises, but growing number is looking either public or private cloud platforms to stream line costs. This transition will happen gradually, but speed seems to be growing all the time.

    Microsoft is indeed moving to the CAM world based on the business drivers coming from our customers, since App/CAM world is something which is based on the feedback and input from our customers, it’s not just something people in Redmond came up with in some rainy Monday. Customer requirements always drive our product design, so that we can address those needs, what our customers have.

  34. Uday Joshi says:

    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.

  35. Vesa Juvonen says:

    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.

  36. Luis says:

    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

  37. Vesa Juvonen says:

    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.

  38. Ravi Chinni says:

    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

  39. Vesa Juvonen says:

    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.

  40. Vili Bogdan says:

    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.

  41. Yvan says:

    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.

  42. Shriram says:

    Hello Vesa,

    We are facing exception when we try to localize the site columns from CSOM code. Our console code provisions OnPremise sites. We have already added additional languages for the root site(fi-FI & sv-SV).

    Exception is "Field or property "TitleResource" does not exist." similar one is for "DescriptionResource" and it appears when we try to execute the query against a web context i,e. web.Context.ExecuteQuery();

    Can you please help?

    Thanks for your reply!

  43. Vesa Juvonen says:

    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.

  44. Shriram says:

    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!

  45. Vesa Juvonen says:

    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.

  46. Shriram says:

    Thanks for the clarification Vesa!

  47. CG says:

    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.

  48. Vesa Juvonen says:

    Hi CG,

    Recommendation is to avoid sandbox solutions and to use CSOM to create needed objects. See following resources for the Office 365 recommendation:

    http://aka.ms/OfficeDevPnPMSDN

    http://aka.ms/OfficeDevPnPMVA

    aka.ms/OfficeDevPnPTraining