In SharePoint 2007 Microsoft introduced the ability to extend SharePoint’s capabilities with ‘Full Trust’ or ‘Farm Solutions’, which was a major improvement in standardizing the packaging and deployment of customizations.
Such a solution could be sets of custom web parts, timer jobs and web templates written in server-side languages like C#. All code had ‘Full Trust’ (or at least more than required) permissions on the SharePoint farm, therefore the name ‘Full Trust Farm Solution’ was adopted.
Read here about Microsoft’s guidelines for Full Trust solutions in SharePoint 2010.
Microsoft introduced the concept as it wanted a standard way that companies and partners could customize SharePoint and add new features. SharePoint was starting to become very popular around the time of the 2007 release, and as a result many people were looking at how to extend or expand what came ‘out of the box’. Full Trust Farm Solutions were the perfect answer. Or so it was thought at the time.
This approach gave developers the tools to customize SharePoint in any way they needed, but it did have several drawbacks. As all code runs on SharePoint servers, poorly written code could decrease performance significantly. These performance issues would affect every application running on that server, not just SharePoint. Full Trust Farm Solutions also have security concerns, because the code has full control within the SharePoint farm. Badly architected code can thus in theory affect the entire SharePoint solution.
A victim of success
Microsoft never anticipated that Farm Solutions would be such a big success, but they were and became immensely popular with developers.
To try and address some of their drawbacks Microsoft introduced ‘Sandbox Solutions’ in SharePoint 2010. This approach offered a subset of the functionality of Full Trust Farm Solutions, with code being forced to run in its own separate sandboxed process.
However the functional limitations meant Sandboxed Solutions were always seen as a poor relation to Full Trust Farm Solutions. Microsoft decided to deprecate/discourage Sandbox Solutions in SharePoint 2013, meaning that they should no longer be used for user code.
A new approach with SharePoint 2013
Microsoft introduced the ‘App Model’ in SharePoint 2013, radically changing the whole approach to custom code development. All customizations are either run in the browser using JavaScript, or on another platform with externally hosted Apps. No server side code is run on the SharePoint servers anymore, meaning badly written code cannot affect core SharePoint services.
Apps can be deployed to both SharePoint 2013 ‘On Premises’ environments as well Office 365. In Office 365 the App Model is the only approach developers have, as Microsoft can be much stricter about the code it allows to run on its own servers.
Five reasons to avoid ‘Full Trust’ completely
Let us look at five key reasons that ‘Full Trust’ solutions should be avoided, and why the alternative App Model is much better:
1. Memory issues
Server side code that talks directly to SharePoint is prone to memory leaks. If SharePoint ‘best practice’ code guidelines are not followed strictly, the memory usage of the IIS web sites hosting SharePoint applications will increase, decreasing performance of the SharePoint farm.
SharePoint Apps don’t have these issues, because all code is run outside of the SharePoint farm.
2. Security
Full Trust Farm Solutions run either in the context of the web application (IIS Application pool) or the timer service (Farm service account). In either the code has almost full access to the SharePoint farm, and even to other web applications. So, for every Farm Solution that is deployed, security checks need to be performed manually to make sure no malicious code is being run.
SharePoint Apps run in their own context, the so-called ‘App Web’ or a ‘Provider Hosted Web’. Permissions to existing webs need to be granted explicitly.
3. Not Cloud proof
Farm Solutions cannot be deployed to Office 365/SharePoint Online. The only way to leverage Farm Solutions in the Cloud, is by creating a ‘Provider Hosted App’ and point to an On Premises solution.
A SharePoint App can be deployed to both On Premises as well as to Office 365.
4. Harder to upgrade
Farm Solutions are tightly coupled to SharePoint and the code runs in the same context as SharePoint, making them harder to upgrade. The more custom code that exists in a Farm Solution, the more effort is required to upgrade. This often means that the entire SharePoint farm is unavailable during upgrade of the customizations.
SharePoint Apps on the other hand are loosely coupled with SharePoint. Apps have a minimal dependency on SharePoint, making them easier to upgrade.
5. Dependent on .NET framework
SharePoint is built on the .NET framework. Full Trust Farm Solutions are required to be written in the same .NET version as the version the solution is deployed to.
For example SharePoint 2010 is built on .NET 3.5, meaning all solutions must use the same version. They cannot take advantage of the improvements in versions beyond .NET 3.5.
SharePoint Apps, in particular ‘Provider Hosted Apps’, can be written in any language and hosted on any platform. They can even be hosted on a Linux server and written in PHP.
Apps are the future
Full Trust Farm Solutions allow almost any type of functionality or customisation to be created, however they have big drawbacks with security, performance, and upgradeability. Therefore Microsoft is heavily pushing Apps as the best practice solutions to create custom functionality for SharePoint. Not only are they a better way of creating great solutions, but they can be deployed easily to both On-Premises and Office 365 environments.
Get started with App development on dev.office.com and our SharePoint Code Migration Assessment.
Still stuck on Full Trust code?
This does not mean that you can’t already prepare the move to the app model and save time and money during a future migration. The SharePoint App model utilizes common web development best practices and strategies that can be used already even when your are still on SharePoint 2010.
The solution
Rencore Code gives powerful insights and best-in-class analyses, reports, and action plans for you to stay in control of your SharePoint code. This includes validating code, XML, HTML, ASPX, JavaScript, CSS and Resource files for best practices, memory leaks, security, deployment, migrateability.
