Forum Discussion

DaR0GaE1's avatar
DaR0GaE1
MVP
Dec 24, 2016

SharePoint Server Full Trust solution VS App or Add-ins

Dear SharePoint members of the Tech Community,

 

I’d like to get some constructive feedback regarding Full Trust Solutions Vs App or Add-Ins. I’ve received mixed responses on this topic and hence I am posting this topic here for a healthy discussion. I’ve done my research and below are the URLs that I have posted but what I am looking for are answers to the following questions-

  • Are hosting environments still using Full-Trust solutions and when?
  • Difficulty level in configuration requirements for Add-in.
  • Any unexpected problems or limitations in the add-in model that didn’t exist in the Full-Trust solution?
  • Anything else both farm, site collection admins or developers have noticed in either model?

 

Below are my research URLs and I welcome any others that you might have.

 

MSDN article of Overview of apps for SharePoint 2013

Architecture models for SharePoint provider hosted add-ins in on-premises

Transform farm solutions to the SharePoint add-in model

New name for apps for Office and SharePoint.

SharePoint 2013 Development (Apps versus Solutions)

 

Thanks in advance for all your feedback!

2013
2016
App
developer
sharepoint server
  • Andrew Koltyakov's avatar
    Andrew Koltyakov
    MVP
    Dec 25, 2016

    Hi Daniel,

     

    Full Trust (aka Farm) Solutions have absolutely no future, imo. Even if a company is going to use On-Premises it still risky to continue with SSOM. It is risky strategically and also bring some inconvinuence from technical side of view.

     

    In our team we ended up avoiding SSOM solutions since the times of SP 2010 as much as possible. There are cases when SSOM is the only On-Premises way to achive a specific task, where Full Trust Solution can be reasonable. But persentage of such cases is really tiny. WSPs, even with declarative CAML only, are banned on the projects almost always too.

     

    At the same time, on the On-Premises rather as SharePoint Online, Add-ins are also not very welcomed, with some exceptions of cource for Provided Hosted Add-ins as a containers of a logic that should run with elevated privileges.

     

    So we ended up with the following approach which works for us in 80% of the project's cases:

     

    • Artifacts provisioning/re-provisioning (any time update) with use of CSOM and SPMeta2 in particular (a lot of folks prefer PnP over SPMeta2, but for us code base provisioning approach is a priority);
    • 60-90% of the logic (JSOM/REST) is on client side which stores in SharePoint assets (in /_catalogs/masterpages/...) an lives in SharePoint as a custom actions (scriptlinks), client side rendering (CSR), CEWPs (all of these can be a part of a model provisioned with SPMeta2 during deployment, but published in a robust way with use of Gulp tasks and SPSave during development stages);
    • Scheduled processes talking with SharePoint with use of CSOM in .Net assemblies or REST in Node.js solutions, using Add-in Only context of a service account credentials, executed as an Azure Web Job or Windows Schedule Task;
    • Custom Web Services for dealing with 40-10% of solution's logic that should do more than a user context can.

     

    Such approach works for our team for On-Premises and SharePoint Online as well in most use cases. Development patterns are almost identical. Delivery livecycle is shorter in times as if it were a Full Trust Solution for On-Premises, maintainence and patching in 10-20 times quicker, easier and stable.

    Of cource from task to task there could be an exeptions, which are only for 20% other use cases.

     

    Hope my story can be helpful for your analysis. Will be glad to answer your questions in details.

Resources