Visual Studio 2010 makes it really easy to add and deploy solutions
when you are developing, but you may eventually want to deploy those
solution packages elsewhere right? We can still use stsadm, but that is
effectively considered deprecated now in favor of PowerShell. In the
past to add a solution, we used an stsadm command like the one below.
In today’s example, we’ll be working with a package called
SharePointProject2.wsp on my server named sp2010.
stsadm –o addsolution –name SharePointProject2.wsp
To
get started with PowerShell, run the SharePoint 2010 Management Console
located in your Microsoft SharePoint 2010 Products folder on your start
menu. This automatically loads the Microsoft.SharePoint.PowerShell
snappin so that we can execute SharePoint commands. To install a
solution we use the
Add-SPSolution command. If you are using a Sandboxed solution you would use
Add-SPUserSolution
instead. It takes just one parameter, –literalpath, which is the path
to the solution file. One thing that is different is that you must
specify the full path to the file for some reason. I haven’t been able
to get it to take a path to the solution in the current folder even if I
make use of .\ before the filename. Here is an example.
Add-SPSolution c:\code\SharePointProject2\bin\debug\SharePointProject2.wsp
In
this case you don’t actually have to type –literalpath before the
parameter. This is what it looks like when executed. You can see that
it displays the id of the solution along with its deployment status.
Now we need to deploy the solution. In the past, we used an stsadm command like the following.
stsadm –o deploysolution –name SharePointProject2.wsp –url http://moss-server –allowCasPolicies –immediate
We
would also follow this up with a call to stsadm with the execadmsvcjobs
operation. To do the same operation in PowerShell, we use the
Install-SPSolution command (again use
Install-SPUserSolution for
Sandboxed solutions). You can use the Get-Help command (i.e.: Get-Help
Install-SPSolution) to get more information on a command but it’s not
always obvious what it is expecting as you can see below. That is why I
am writing the post today.
The first parameter you need is the
–Identity parameter.
This is the name of the solution package (i.e.: MySolution.wsp).
Depending on if you are using the GAC or Code Access Security, you will
specify either –
GACDeployment or –
CASPolicies. You then need to specify a specific web application using the –
WebApplication parameter or –
AllWebApplications
to deploy it to all web applications (assuming the manifest allows
it). If you need to force the deployment, you can still use the –
Force command. Here is what an install command might look like.
Install-SPSolution –Identity SharePointProject2.wsp –WebApplication http://sp2010 -GACDeployment
I’ll
point out that executing this command actually does do the deployment
operation. You don’t have to fire off something to execute a job later
like you did with stsadm.
You might want to update your
solution, so we’ll talk about how to do that as well. Here is what your
stsadm command might have looked like in WSS3. Which would also be
followed up with an execadmsvcjobs operation.
stsadm –o upgradesolution –name SharePointProject2.wsp –filename SharePointProject2.wsp –immediate –allowCasPolicies
The upgrade solution syntax is similar to the others. We just have to specify an identity and a literalpath with the
Update-SPSolution command.
The identity is the name of the package on the server to upgrade and
the literalpath is the full path to the new solution package on the file
system. Here is what that might look like.
Update-SPSolution –Identity SharePointProject2.wsp –LiteralPath c:\code\SharePointProject2\bin\debug\SharePointProject2.wsp –GACDeployment
We’ve
talked about everything else, so we’ll finish it up by talking about
retraction and removal. To retract a solution we use the
Uninstall-SPSolution
command. By now you are probably noticing a pattern in the way things
are named. Install –> Deploys, Uninstall –> Retracts. It also
just uses the
-Identity parameter and the –WebApplication parameter. You can also use the –
AllWebApplications
parameter to retract it from all web applications. Many of these
commands may prompt you with an “Are you sure?” type prompt. You can
skip this prompt by adding a –
confirm parameter. Here is what it looks like.
Uninstall-SPSolution –Identity SharePointProject2.wsp –WebApplication http://sp2010
Lastly, to remove the package from the solution store, we use the
Remove-SPSolution command. It just takes the name of the package.
Remove-SPSolution –Identity SharePointProject2.wsp
I
hope this helps. If you’re like me, it’s one thing to see the docs on
something, but I like to see real examples. There aren’t any examples
in the Get-Help command yet. This should cover all of the common
commands that you probably used to used with stsadm in regards to
solution deployment. The nice thing is that you can script these things
together very easily and create highly flexible PowerShell scripts.
Expect a few more posts soon on the basics of working with PowerShell
and SharePoint 2010.
To learn more about using PowerShell with features, see
Activating and Deactivating Features with PowerShell
Reference:
http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2009/12/02/adding-and-deploying-solutions-with-powershell-in-sharepoint-2010.aspx