The Need for SharePoint Code Analysis

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.

People behind

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

Comments (3)

  1. Boyd Collins says:

    Hi Torsten, I really like your work on the SPCAF and I want to use it to enforce standards for our SharePoint applications. Unfortunately, I cannot add new custom rules, even though I follow all the instructions in the SDK. My new rule never gets recognized and executed. The problem is that I don't know how to add the new rule declaration into the ruleset. The documentation states, "Build your project and copy your library to the installation directory of SPCAF (root directory). During next analysis your assembly will be loaded." but the new rule is not associated with any ruleset. Your help would be most appreciated.

  2. Hi Boyd,

    Thank you for using SPCAF.

    If you followed the instructions in the documentation your rule should be loaded but maybe we are missing something in the docs so I will summary the major steps for everybody:

    During analysis the SPCAF engine searches the installation directory for assemblies and scans for all classes which are inherited from "SPCAF.Sdk.Rules.Rule".

    To be able to load the custom rules the following prerequisited must be met:

    – Using the correct version of the SDK: The version of the SDK must be the same version as the version of the SPCAF.Engine.Dll. Current version is (only limitation in BETA version)

    – The target framework version must be set to 4.0

    – The custom rule must be public

    – The custom rule must contain the required "RuleMetadata" which defines the name and id of the rule

    All loadable rules are used during the analysis except if they are disabled in the used ruleset or if the category to which the rule belongs is disabled. You don't need to edit any ruleset file.

    During each run the rule scan is performed and assemblies are not cached. So reinstallation of SPCAF is not required to load custom rules.

    To ensure that your rule is loaded you can try the steps for debugging (see above) or you can throw an exception in your rule and check the report if this exception is listed in the "Exception" list (last section of the report).

    You can also run the ruleset editor from the installation directory (SPCAF.RulesetEditor.exe). Your rule should be listed in the treeview.

    You could also send your custom rule project to feedback at spcaf dot com and we will try to help you.


  3. AdalineAchani says:

    You're right, With the help of Microsoft Sharepoint you can access your information on the network, it's a secure platform to partake if you want the best answer or advise regarding Sharepoint Visit

Skip to main content