In this article | In this page |
---|---|
SPBlaze processes an XML file. The script can be executed with four different options, these are ALL, REMOVE, INSTALL, DEPLOY.
For example;
.\spblaze.launch my.config.xml DEPLOY |
The above code block will launch the deployment with the DEPLOY action. See below for details about what the different actions involve.
The process the script follows is shown in the following diagram:
Diagram - Process Overview (Created using Gliffy, a cool plugin from Atlassian)
This action will process the entire XML file. The process steps are:
This action will remove all solutions from the solution store. If they are deployed they are forably removed.
This action will add solutions to the solution store only.
This action processes the majority of XML file. It runs all aspects other than adding and removing solutions.
Sandbox Solutions are deployed during the DEPLOY action and NOT during the INSTALL action. While this may seem counter intuitive the reason for this is that the site collection may not exist when the INSTALL action is executed. As a Sandbox solution must be uploaded to a site collection is is processed during the DEPLOY action. |
Version 1.0 of the scripts do NOT activate the Sandbox solutions. You must do this manually or with an external script. |
If you're keen, break open the file spblaze.launch.ps1. Scroll to the very end, you will notice the following:
if ($Action -ieq "Remove" -or $all) { ExecuteAsJob $InputFile "RemoveSolutions" $YesToAll } if($Action -ieq "Install" -or $all) { ExecuteAsJob $InputFile "Solutions" $YesToAll } if($Action -ieq "Deploy" -or $all) { ExecuteAsJob $InputFile "PreDeploymentScripts,Quotas" $YesToAll ExecuteAsJob $InputFile "WebApplications" $YesToAll ExecuteAsJob $InputFile "PostDeploymentScripts" $YesToAll ExecuteAsJob $InputFile "FinalisationSteps" $YesToAll } |
When the main script is called, it executes different steps. You can do this yourself by calling the spblaze.library.ps1 file directly and passing in the appropriate parameter.
This is helpful when you are debugging parts of the xml file that are failing and you don't want to process everything.
If you call the library script directly, be aware of what code is running within your single powershell session. It is possible to get assembly mismatch errors because and old copy of your DLL is still loaded in the app domains memory. That is the reason for the launcher script. |