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
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 the full-trust solutions 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 websites hosting SharePoint applications will increase, decreasing performance of the SharePoint farm.
SharePoint apps don’t have these issues because all code runs outside of the SharePoint farm.
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 context, 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-premise SharePoint sites 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 customization 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 even when you are still on SharePoint 2010.
You can find the original blog here.