Sunday, 20 March 2011

Extract WSP Solutions from SharePoint using PowerShell

There will be occasions when you will find it really useful to be able to extract a WSP solution from the SharePoint solution store.  This is not something that you can do out of the box, I’m not sure why, possibly to protect the intellectual property of third party solution providers perhaps?
I’m not saying that you should be extracting WSPs so that you can go poking around in other people’s solution packages, but there are definitely valid reasons for needing to extract those solutions.
The two main legitimate reasons I can think of for needing to extract a WSP are as follows:
1.   Your company does not have an appropriate source control system and your solutions have been developed by a third party.
2.   You need to audit any custom solutions that have been created.
Regarding the second point above, there have been a number of times when I have had to perform an audit of a customer’s SharePoint system as part of IMGROUP’s Health Check service.  The reason for wanting to poke around in the WSP solution package is to verify whether or not customisations have been made according to best practice.  For instance, in one particular instance a third party had assured the customer that all their customisations had been packaged as part of WSP packages, but by extracting the few WSPs that were in the solution store, I could see that this was in fact not the case.
Another example that is quite pertinent at the moment is where you need to assess what customisations are in place prior to performing an upgrade to SharePoint 2010.  The “preupgradecheck” command that is a part of stsadm is only available as part of Service Pack 2 for MOSS 2007, as well as ideally requiring a number of additional cumulative updates.  If your environment is currently at Service Pack 1 and you are fairly risk averse, performing an upgrade to Service Pack 2 purely to get an understanding of what customisations have been made may not be particularly desirable.  Instead, most customers that I am working with will include the Service Pack 2 upgrade as part of their implementation plan, but want some early visibility of their customisations so they can make steps to validate them against the new product.
The following simple PowerShell script will iterate through the solution store and write the WSP packages to file:
Start-Transcript "c:\wsp\transcript.txt"

$solutions = [Microsoft.SharePoint.Administration.SPFarm]::Local.Solutions;
foreach ($solution in $solutions) {
   $solution.SolutionFile.SaveAs("c:\wsp\" + $solution.Name);

The above script uses the Reflection namespace to perform an Assembly load of Microsoft.SharePoint.dll from the GAC.  Since the dll is being loaded in this way, the script can be run in a standard PowerShell console.  If your environment is running on Windows Server 2003, PowerShell can be downloaded and installed from the following link:


  1. I like this, nice and straight forward. Cheers

  2. What do you make of this error that comes up? There are about three of these when I run your script.

    Exception calling "SaveAs" with "1" argument(s): "X:\SPBackup\Stage\Nov 9 2011\WSP\my.wsp could not be
    created because the contents could not be found under id 7f6c6b5b-ae55-47a7-91a7-a454f2f49969 in the configuration databas

  3. Saved me...! Nice Post.