SharePoint has grown over years and is today widely used in companies and businesses as intranet or internet portal and as collaboration plattform. One major reason for the success of SharePoint is the extensibility. The powerful API provides “boundless” possibilities to customize and extend SharePoint with custom code.
Risk of Customizations
Sometimes this extensibility is good and sometimes it is bad. Inappropriate customization 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 customizations which leads to huge efforts to migrate at least the stored data in SharePoint.
Rules and Policies
But prohibit the customization 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 customize SharePoint but prevent that the code impacts SharePoint in negative ways.
One way is to establish rules, conventions and policies which define how SharePoint customization must happen and also which type of customization is not allowed. These rules and policies must be defined (e.g. in customization 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 limititation: they cannot analyze SharePoint XML code. The tools can only analyze 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 analyze the solution packages and can not detect if a SharePoint system file is overridden during depoyment.
Thats why SharePoint Code Analysis Framework (SPCAF) has been developed: SPCAF “reads” SharePoint solution packages (.WSP) and “converts” the SharePoint XML into an analyzable structure. This new structure of the code is used by 4 major tools to analyze 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 analyzes 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, qualiy managers or IT operators to ensure that SharePoint code is conform to their customization policies and conventions.
The SharePoint Code Analysis tools have been developed by Torsten Mandelkow and Matthias Einig. Both are working since many years as consultants, architects and developers in SharePoint development projects. During their work they were faced with lots of problems in SharePoint development and started to develop tools for their own to make SharePoint development easier and faster and to improve the quality of SharePoint code. Some of these tools have been published and some of them can be found on codeplex.com.