Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I am trying to deploy or update a WSP solution to SharePoint in a script using Update-SPSolution. The problem I have is that if this is the initial install I need to use Add-SPSolution and then Install-SPSolution to deploy it and then run Update-SPSolution. If the WSP has already been deployed I can just run Update-SPSolution. How do I check if the WSP has been Added and or Deployed to the Farm?

share|improve this question

4 Answers 4

up vote 5 down vote accepted

Get-SPSolution returns an array of SPSolutions added to the farm. You can compare a solution's name or GUID (SolutionID) to your solution and check the Deployed property to see if it's currently deployed.

For example:

PS> Get-SPSolution

Name                       SolutionId                           Deployed
----                       ----------                           --------
intranet.brand.wsp         7f332ea0-352e-180a-9c02-2b30acfe35f6 True
intranet.mysites.wsp       db2e49c9-b32b-1c62-878b-09a676320eac True
intranet.publishing.wsp    12cbd2db-5e44-1282-bb1c-4223acb9ccf5 True

PS> $solutions = Get-SPSolution

PS> foreach($solution in $solutions) {
>> if ($solution.Name -eq "intranet.publishing.wsp") {
>> Write-Output "intranet.publishing exists"
>> }
>> }
>>
intranet.publishing exists
PS>
share|improve this answer
1  
Why not just use Get-SPSolution -Indentity "intranet.publishing.wsp" | select deployed, lastoperationresult –  Anders Rask Sep 24 '12 at 13:12
    
Yes, that would work as well and I do quite like your approach. –  shufler Sep 24 '12 at 18:08

One thing you may want to do is close your PowerShell window (PowerShell ISE or PS Management Shell) - apparently the WSP referenced by the Upgrade-SPSolution caches the WSP.

Here's a description of the issue - similar to my own.

Jeremy Thake's webcast video references this issue, if you managed to catch it. I hope this is resolved in SP 2013.

share|improve this answer
    
It is not a SharePoint issue, but a PowerShell issue, so dont look for SP2013 for solutions to this. The problem is that PowerShell caches its requests. We have build a deployment framework that will spawn new processes (Start-Process PowerShell -STA) hence avoiding caching the instantiated object properties –  Anders Rask Sep 24 '12 at 13:18

Every time that I have tried to use use the Update-SPSolution command it never works the way I think it should so instead, I always use the deactivate-retract-delete-add-deploy-activate approach just as if it were a new solution.

Per TechNet : "The Update-SPSolution cmdlet upgrades a deployed SharePoint solution in the farm. Use this cmdlet only if a new solution contains the same set of files and features as the deployed solution. If files and features are different, the solution must be retracted and redeployed by using the Uninstall-SPSolution and Install-SPSolution cmdlets, respectively."

There are more details on MSDN as well

share|improve this answer
    
As much as I hate it, the deactivate, retract, delete, add, deploy, activate dance is effective. It reminds me though of those installers that would pop up with a message box "Product X is already installed! Uninstall Product X before upgrade to Product X.1!" We use Update-Solution whenever we're deploying a solution that has been updated (bug fixes, feature enhancements, etc) –  shufler May 23 '12 at 19:22
    
Update solution works as designed: if you have new features or deleted features, it will not re-activate them. However in my tests Update-SPSolution will detect new TemplateFiles (hence added solution files) and deploy these. –  Anders Rask Sep 24 '12 at 13:11
    
I ran Update and whilst the GAC said it had the latest version of the DLL (and the sites appeared to recycle), it didn't use the latest DLL version... so yes, full remove/re-add needed. –  PeterX May 23 '13 at 7:36

What's the scenario here? Are you adding a new WFE and want to know if the solution has been deployed to that new WFE, or are you upgrading an existing solution that's already deployed? Update-SPSolution will not "re-deploy" per say. It will update components of that solution that have changed, but unless you're handling changes to the solution with code using feature version, new items will not be deployed as part of an Update-SPSolution call.

For example, if you add a new module with new masterpages and package, then run Update-SPSolution, your new module won't be processed. Those initial deployment tasks don't fire as part of an update. You would need code to handle the difference in version between what's on the server and the version you're now deploying, and instruct that code that if the version is n.n.n.n to process that module since it wouldn't have been there. There's a great webcast by Jeremy Thake on that side of feature development.

If you're just looking for solution status, there's a couple good blog posts out there that have methods for grabbing the last operation status of a solution with PowerShell... those are probably a good starting point (this one for example).

share|improve this answer
    
What would you recommend in that case. We can retract the solution and redeploy it on the DEV and TEST servers but how do we update the Production servers without losing our data? –  Lukasz May 23 '12 at 18:20
    
Update-SPSolution relies on version information in the solution. Unless you have your deactivate event set to remove content, nothing should come out. Deactivating a feature that created a list doesn't delete the list unless you've told it to do that. The right approach would be to build your features with version information, per Jeremy's webcast. This would allow you to use Update-SPSolution. –  webdes03 May 23 '12 at 19:10

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.