Share via

SharePoint 2010: Reverse Engineering SharePoint WSP Packages

  • Article

Reverse Engineering SharePoint WSP Packages

Disclaimer: Please note that this article is scoped to internally developed WSP Packages only.  The terms and conditions that you accept when purchasing and installing a commercial third party product distinctly prevent you from trying to reverse engineer these products.

Introduction

The SharePoint platform (via its API / Client Object Model) is fertile territory for developers.  Should a third party product or Open Source offering not meet a specific business need, SharePoint offers you enough brevity to create your own.  However, deviation from the “Out of the Box” (OOTB) product does come with a few caveats.  These solutions should ideally be documented for: -

  1. Following Back-up and Restoration procedures
  2. Being included in Disaster Recovery and Business Continuity procedures
  3. Being included within Administrative and Configuration Documentation

This article is intended to provide guidance to reverse engineering internal / bespoke solutions should documentation be inadequate or lacking entirely for them. 

Audience

This article is primarily aimed at Administrators or those that have an intermediate knowledge of SharePoint knowledge.  Terms such as Features, Site Collection and so on should be familiar words.

Getting Started

  1. First of all, locate the WSP package that needs to be investigated.  These can typically be identified by looking at the Web Application or Site Collection features.  The OOTB features are clearly labelled as are paid third party ones.  Alternatively, you can bypass this step and look straight in the Central Application Solutions Gallery
  2. Download it / get it from the store
  3. Rename the .wsp to a cab format.  Accept the warning which advises you the file may become unusable
  4. Extract the cab contents somewhere to your drive. 
  5. Browse to the directory and have a look at the extracted files
  6. An important file of note here is the manifest.xml. This defines the list of features, site definitions, resource files, web part files and assemblies.  An example of a Manifests.XML file can be seen below
  7. Using the information within, a SharePoint Administrator will glean greater insight into what files are being placed where and if any further investigative work needs to be carried out.

Delving Deeper

There is only one scenario where a deeper level of reverse engineering will be needed and this will be looking at the source code of web parts.  A useful utility for this is the RedGate .Net Reflector.  Licensed products will almost certainly have additional protection

See Also

An important place to find a huge amount of SharePoint related articles is the TechNet Wiki itself. The best entry point is SharePoint Resources on the TechNet Wiki