SharePoint has grown over years and is today widely used in companies and businesses as intranet or internet portal and as collaboration platform. One major reason for the success of SharePoint is the extensibility. The powerful API provides “boundless” possibilities to customise and extend SharePoint with custom code.
Risk of Customisations
Sometimes this extensibility is good and sometimes it is bad. Inappropriate customisation can lead to a SharePoint environment, which cannot be managed anymore. Performance problems, crashed environments and unsatisfied users are the results. And often the migration to newer versions of SharePoint is impossible because of these customisations which leads to huge efforts to migrate at least the stored data in SharePoint.
Rules and Policies
But prohibit the customisation of SharePoint is not an option for many companies because this would constrain the potenzial of SharePoint. So we need to find a way to customise SharePoint but prevent that the code impacts SharePoint in negative ways.
One way is to establish rules, conventions and policies which define how SharePoint customisation must happen and also which type of customisation is not allowed. These rules and policies must be defined (e.g. in customisation policies) and must be accepted by all involved people, like developers, architects and also by the business side because these policies may limit the adaptability of SharePoint.
You cannot manage what you cannot measure
When these policies and rules are defined they must be controlled and measured, ideally with tools for code analysis, like FxCop, StyleCop, FxCop Metrics, SPDisposeCheck, CAT.NET etc. However, all these tools have one crucial limitation: they cannot analyse SharePoint XML code. The tools can only analyse assemblies and C# source code, but they cannot find errors or issues in the XML of Features, Content Types, Solution packages, Site Definitions etc. The tools can also not analyse the solution packages and can not detect if a SharePoint system file is overridden during deployment.
Thats why SharePoint Code Analysis Framework (SPCAF) has been developed: SPCAF “reads” SharePoint solution packages (.WSP) and “converts” the SharePoint XML into an analysable structure. This new structure of the code is used by 4 major tools to analyse der SharePoint code:
- SPCop checks the code for violations against more than 300 rules.
- SPMetrics calculates SharePoint code metrics and helps for instance to measure the complexity of the code.
- SPDepend analyses dependencies between the SharePoint artefacts (like Features, ContentTypes etc.) and detects dependencies to external components.
- SPInventory creates a detailed inventory of all elements in SharePoint packages.
These tools can be used by architects, developers, quality managers or IT operators to ensure that SharePoint code is conform to their customisation policies and conventions.
