Custom Code: The Missing Piece of the SharePoint Governance Puzzle

Matthias Einig

by Matthias Einig on 12/22/2014

Share this:

Article Details

Date Revised:

Applies to:
Code Analysis, Custom Code, Development, governance, SharePoint

Lots of companies have been running SharePoint systems for many years. Some have built up a lot of expertise, some even have dedicated support professionals and teams in place. Yet even for these very mature organizations, ‘governance’ can still be a bit of a mystery. Any company running SharePoint needs to think about governance and what it means to them. According to Microsoft, the definition of governance is:

"Governance is the set of policies, roles, responsibilities, and processes that control how an organization's business divisions and IT teams work together to achieve its goals."
Failing to think about these things means a SharePoint portal can become disorganized, users can get confused, people don’t know where to go with questions, and there is no clear plan around the future direction of the system. Whilst many companies struggle with governance, the SharePoint community is particularly good at trying to help. Besides a lot of good articles on Microsoft TechNet, many posts have been written about governance in SharePoint projects, for example: Codeplex even hosts a SharePoint Governance tool by Bill Baer, Senior Technical Product Manager at Microsoft, to make the process easier (please note it is currently in alpha status). However, all these articles are usually focussing only on IT Management and Information Management Governance. One topic that is nearly always missed in any governance conversation is that of Application Management & Governance of the custom code. Microsoft explains the application management for custom solutions in it's governance poster (PDF) and TechNet article for SharePoint 2013. Microsoft SharePoint 2013 governance poster But what are the controls and processes in place around customizations? Let us look into this area in a bit more detail.

No, I don’t know who wrote that code, but it seems to be working!

Without proper governance in this area, it can become unclear who wrote customizations, what exactly each one is doing, and what the dependencies are to keep them working. People come and go, requirements change, and without proper governance it can become impossible to understand the status or impact on your farm. If something goes wrong, it could feasibly cost the company time and money, so something needs to be done. As I have discussed previously in my blog, substandard customizations can have a negative impact on a SharePoint environment, both on-premises or cloud hosted:
  • Performance: Farm solutions can have a negative performance impact on the entire SharePoint farm, so not only on the web application they were deployed to. For example, a malfunctioning timer job can block other timer jobs. In the brave new app world, bad performance is usually exposed on the users' side and often caused by unnecessary requests to the servers and inefficient JavaScript code. (I highly recommend the SharePoint JavaScript Context Development blog series of my colleague Hugh Wood to learn more about coding JavaScript the right way for SharePoint.) As you can imagine, bad performance can not only cause problems in the infrastructure, but also a lot of frustration for users and eventually it slows down or prevents the adoption of SharePoint as a business platform.
  • Security: As the name “Full trust farm solutions” suggests, they have almost unlimited access to the SharePoint farm. Code can run under the web application pool account and timer job code runs under the timer service account (in most scenarios the farm account). Therefore it’s really important to check every full trust farm solution before trusting it, especially with third-party add-ins. But also the new app model poses an entirely new security risk, now that a lot of code is running on the client side in a maybe uncontrolled environment. The risks of XSS (cross site scripting), SQL injections or other security vulnerabilities have been there before, of course. But now when running more and more code in a shared environment hosted in the cloud, like in SharePoint Online/Office 365, suddenly these security gaps are exposed to the public, making it easier for perpetrators to gain access or even modify your data.
  • Dependencies and stability: Farm solutions and apps depend on many other components, which may have an impact on stability (e.g. third-party assemblies or JavaScript libraries, resources etc.). The dependencies may not be clear from the documentation and are often only visible by trial and error.
An important part of any governance strategy is to understand what customizations you have, what they do, and exactly how they have been implemented.

How can we write good SharePoint code?

Quite a while ago (in 2009) Microsoft published 10 best practices for SharePoint farm solutions. Even though the blog focuses on SharePoint 2007, much of it is still valid for farm solutions in SharePoint 2010 and 2013. The problem with it and similar guidance on blogs is that a lot of it became obsolete with the shift to SharePoint Online. Pay attention to the requirement to prepare your code now for future updates and migration if you are still developing for SharePoint on-premises. Even worse, thousands of SharePoint developer-focused blogs and forums on the internet are full of false or at least questionable guidance and code solutions. Sadly, many developers tend to just copy & paste code snippets of a solution without even giving it a thought or thorough investigation if this piece of code should be really used. This might minimize the costs and time to finish their projects, but in the end, the customer will pay the bill when realizing that poor code caused high maintenance and operational costs, or needs to be re-implement entirely when upgrading to a new SharePoint version. Here are a three examples that might make you reconsider your current practices and show pretty clear how hard it is to get the right up-to-date guidance what to do and what to avoid:
  1. Use WebTemplates instead of Site Templates when creating custom templates. While this is per se true for full trust code, the recommendation nowadays is to avoid as much declarative code as possible, including List definitions, Content Type definitions, Site Column definitions and List Instance definitions. These are only partly available in SP Online (e.g., through sandboxed solutions) and cause major maintenance problems when changes need to be applied. To see how to code these types of SharePoint artifacts with CSOM instead, I highly recommend you to take a look at the Microsoft Office Developer Patterns & Practices open source project on GitHub, which comes with plenty of samples and common usage scenarios.
  2. Never increase the throttling settings above recommended settings, even if it seems to cause no obvious issues This advice is more relevant than ever! Not only should you not increase the throttling on-premises, you just can't do this in the cloud. So it is wise to just plan your application architecture accordingly so that you don't run into the risk of hitting the limit. This could mean, for example, using a custom database in a provider-hosted app instead of SharePoint lists.
  3. Run SPDisposeCheck regularly to check for memory leaks Checking for memory leaks in full-trust SharePoint code is very important to avoid unexpected behavior of the solution or crashes of IIS. Unfortunately the guidance to use SPDisposeCheck is extremely misleading! SPDisposeCheck had its last release for SharePoint 2010 in 2010. At this time, SharePoint was still running on the .NET Framework 2.0 and hence SPDisposeCheck was built on the same framework. But with SharePoint 2013, the framework version got updated and suddenly SPDisposeCheck cannot analyze the assemblies anymore! Even worse, it is not warning the user, but rather give you a false sense of security by not reporting any issue at all! That is why Microsoft finally removed the download of SPDisposeCheck, but there are of course many places on the web to get it anyway.
Just these examples show you already how hard and complicated it is to make sure your SharePoint Code is of high quality, secure, performant, upgradeable/future-proof and follows best practices. Even harder is to govern this code when it is running and used in your production environment or needs to be migrated to a new SharePoint version. 

The SharePoint Code Analysis Framework (SPCAF) helps you to analyze all the server side (SSOM), client side (CSOM), JavaScript (JSOM) and all declarative (XML, HTML, CSS, ASPX) code of SharePoint solutions (.wsp), apps (.app), executables (.exe) and assemblies (.dll). It allows you to choose between pre-configured or your customized rulesets for different target SharePoint versions and development models, detects code issues, memory leaks, security risks, etc., and generates reports on dependencies, calculates metrics, documents the application and analyzes the ability to upgrade a farm solution to the app model.

Don’t forget custom code in your governance strategy

Governance is essential for a successful SharePoint implementation. While most governance strategies focus on business processes, rules, audits, and strategies, custom code is nearly always forgotten. By following the best practices above, and using automatic tooling, custom code can be made part of the governance strategy. Companies can go even further and record individual features and customizations, the business requirements behind them, a version history of changes, and even the author’s names as part of formal SharePoint governance documentation. Governance, around custom code or more business-focused areas of SharePoint, can be hard to implement at first and difficult to keep going in the long term. But you will certainly be glad you put the effort in when the day comes to update or rework the system.


Topic: Governance

Sign in with

Or register