Before SharePoint 2007, it was difficult to extend SharePoint with custom web parts or bespoke user controls. SharePoint 2007 changed this. It introduced full trust farm solutions, which in turn opened the doors for full blown ASP.NET customizations to be hosted inside SharePoint.
The possibilities were endless, almost everything that could be done in ASP.NET, could now be achieved in SharePoint. The entire ASP.NET stack was available and using native SharePoint API’s custom controls, web parts and timer jobs could ‘talk’ to SharePoint.
“With great power comes great responsibility” is a wise saying, and it also applies to farm solutions in SharePoint. They are powerful and therefore can be risky. Let’s look in more detail at the dangers of SharePoint farm solutions.
You don’t need to rewrite SharePoint functionality
Microsoft released ASP.NET as the successor of the classic ASP. ASP.NET is a framework which allowed developers to build rich and powerful websites. When Microsoft opened the doors to ASP.NET development in SharePoint with farm solutions, it attracted a lot of ASP.NET developers. Despite their good intentions, the most common mistake was to rewrite SharePoint functionality from scratch, instead of extend what was already there.
For example, to aggregate content across a SharePoint portal, a custom ASP.NET web part could be developed that performed this job. However, out-of-the-box web parts were available to achieve this functionality with lower development and maintenance costs. Custom development controls versus out-of-the-box controls always has the downside that it will inevitably contain more bugs. It is a fact of development life. Out-of-the-box controls have been tested thoroughly by Microsoft (and other customers) over a long period of time.
So ASP.NET had many benefits, but it did lead to problems.
A web part can bring down an entire farm
It was rather easy to bring down an entire farm in SharePoint 2007. For example SharePoint 2007 (and previous versions) had no throttling mechanisms to prevent a meltdown after a web part tried to query a list without indices with more than 5000 items. SharePoint 2010 introduced resource throttling which eliminates this risk. But even in the current 2013 version, querying lists larger than approx. 5000 items without indices has a significant performance impact across the entire SharePoint farm.
This is just one example. Over the years we’ve seen many examples of badly written web parts that have brought down entire farms, hit performance, or introduced bugs into the wider farm.
The key is to understand your SharePoint farm solutions code, and audit it to understand what it is doing.
Auditing SharePoint farm solutions is critical
Every farm solution has full trust access across the SharePoint farm (hence the name ‘full trust’) but this means users need to be very careful about the solutions they install. Only administrators have permissions to add new farm solutions, but such is the wide range of tools and products available on the market, that care is needed.
There are a wide number of third party farm solutions available for download, on the web, and available for purchase. It is good practice to audit every farm solution before you give it full trust to your farm, using SPCAF Tools, just to be sure how it is accessing and working with you existing solution.
We’ve explained that, although powerful and very flexible, SharePoint farm solutions can come with a risk. They can decrease the performance of an entire farm, and every farm solution can impose a security threat. The different features in the SPCAF toolkit will help you audit your farm solutions, and keep a close eye on things.
Different analysers like Code Metrics and Code Quality will generate a report that determines the quality of your code in terms, e.g. maintainability, performance, and security. They will make sure that farm solutions provide the customer with the required functionality, without causing any issues!