Last Thursday I wrote about “Exporting SharePoint 2013 Design Packages with PowerShell”. Today I’d like to show you the import function. This functions can be used to handle with SharePoint 2013 Design Packages with PowerShell, e.g. in deployment scenarios. Therefore it should by very useful. (I hope so 😉 ) FEEDBACK WELCOME!!!
You can download the scripts here:
http://gallery.technet.microsoft.com/Export-and-Import-0f41b376
Here you can find the blog article about “Export-SPDesignPackage”: https://blog.kenaro.com/2013/02/14/sharepoint-2013-design-packages-export-with-powershell-part-1-of-2
The import function is called “Import-SPDesignPackage” and here are the details:
Import-SPDesignPackage
Here are some samples
#First sample
Import-SPDesignPackage -SiteUrl "http://sharepoint.local/publishing" -ImportFileName "C:\temp\publishing2.wsp" -PackageName "P2" -Apply $true
#Second sample
( @{ SiteUrl ="http://sharepoint.local/sites/publishing1"; ImportFileName ="C:\temp\publishing1.wsp"; PackageName ="P1"; Apply=$true }, @{ SiteUrl ="http://sharepoint.local/sites/publishing2"; ImportFileName ="C:\temp\publishing2.wsp"; PackageName ="P2"; Apply=$true } ) | New-ObjectFromHashtable | Import-SPDesignPackage
The first sample shows you how to import one design package to a dedicated site. By using the “Apply” parameter the design package will be applied to the site immediately.
The second sample shows you hot to import two different packages to two different site collections. In the sample I use a hashtable for input parameters. They are assigned to the function parameters by “property name binding”. See “http://technet.microsoft.com/en-us/library/hh847743.aspx”: Section “ValueFromPipelineByPropertyName”:
[…]For example, if the function has a ComputerName parameter, and the piped object has a ComputerName property, the value of the ComputerName property is assigned to the ComputerName parameter of the function. The following example declares a ComputerName parameter that is mandatory and accepts input from the ComputerName property of the object that is passed to the function through the pipeline.[…]
Some more details about that. Skip it if you are not interested…
<begin/>
This “property name binding” does not work with hashtables. Therefore I created a helper function “New-ObjectFromHashtable” that creates a PowerShell object (“PSObject”). This function is generic. (It’s also included in the script files.)
On the one hand with “new-object System.Management.Automation.PSObject” you can create a new “empty” PowerShell object that can be used in your script as every other object, e.g. a SharePoint object like an instance of class SPSite. With cmdlet “Add-Member” you can add new members to the object. – On the other hand you have a hashtable with named values. You can access the collection of names = keys and with each key you can access the value. – Let’s combine it: You can iterate through the keys collection and create a new member in an empty PSObject instance.
functionNew-ObjectFromHashtable { #written by Ingo Karstein (https://blog.kenaro.com)# v1.0#Use this function to convert a hashtable to a PowerShell object ("PSObject"), e.g. for using hashtables for property name binding in# PowerShell pipelines [CmdletBinding()] param( [parameter(Mandatory=$true, Position=1, ValueFromPipeline=$true)] [Hashtable] $Hashtable ) begin { $results= @() } process { $r=new-objectSystem.Management.Automation.PSObject$Hashtable.Keys | % { $key=$_$value=$Hashtable[$key] $r | Add-Member-MemberTypeNoteProperty-Name$key-Value$value-Force } $results+=$r } end { $results } }The resulting object can be passed to each “property name binding” enabled cmdlet. – The PowerShell engine tries to match input object property names and cmdlet parameter names. If there is a match the input object property value gets assigned to the cmdlets input parameter.
The cmdlet can also convert a list of hashtables to a list of objects. That is used in the “Import-SPDesignPackage” script.
<end/>
Parameters
Parameter Name | Parameter Set Name | Mandatory? | Position | Description |
SiteUrl | Default | Yes | 0 | Site Url for import |
Site | Site | Yes | 0 | SPSite object for import |
ImportFileName | DefaultSite | Yes | 1 | Filename and path of the design package for import |
Apply | DefaultSite | Yes | 2 | $true = Apply the design package after import$false = Only install the design package for later activation |
PackageName | DefaultSite | No | 3 | Package name. If not specified it uses the file name without extension. The package name will be used for naming the imported file in the solution gallery of the site collection |
MajorVersion | DefaultSite | No | – | Version number of the design package. If not specified it uses “1” for the major version. |
MinorVersion | DefaultSite | No | – | Version number of the design package. If not specified it uses “0” for the minor version. |
The function returns an object for each processed (or not processed) site collection:
Object Property | Description |
SiteUrl | Url of the processed site |
Success | $true = Import and “Apply” (if specified) was successful |
InputFileFound | $true = File found$false = File not found |
InputFileExtensionValid | $true = Input file has extension “.wsp”$false = Input file hat not extension “.wsp” |
SiteFound | $true = The specified site was found |
SolutionFileName | The name of the solution is auto generated from package name or file name and major and minor version number. This is the name of the package in the site collections solution gallery. |
PackageAlreadyExsits | $true = the solution does already exist in the solution gallery. |
Some additions
The import process requires the package to be stored inside the site collection before the the last input step. Therefore the function creates a folder named “tmp_importspdesignpackage_15494B80-89A0-44FF-BA6C-208CB6A053D0” in the site collections root web root folder. In this folder the package gets uploaded. From the location the package is imported. The folder will be deleted after successful or not failed import.