PowerShell caching leads to head-banging
I was attempting to repro a customer issue today and was growing more and more frustrated by the apparent problem that my code was not getting updated with each subsequent build and deployment. It turned out to be something I never would have guessed except through trial and error.
The scenario is using VS 2010 to write a SharePoint 2010 feature that modifies the web.config file for a web application....seems simple enough. In order to make deployment/activation/deactivation/removal a little easier I decided to use some powershell scripts in a window next to my VS IDE:
Add-SPSolution -LiteralPath <full path to .wsp>
Install-SPSolution -Identity <solution name> -WebApplication <url> -GACDeployment
Get-SPFeature | where{$_.DisplayName -match "<solution name>"} | Enable-SPFeature -url <url>
Get-SPFeature | where{$_.DisplayName -match "<solution name>"} | Disable-SPFeature -url <url>
Uninstall-SPSolution -Identity <solution name> -WebApplication <url>
Remove-SPSolution -Identity <solution name>
I started with the code that the customer provided and he had very thoughtfully added a function to log to the event viewer informative, debug-like messages so that he didn't have to actually debug the progress of his feature. After the first iteration, I saw the problem (which I'll discuss in another post shortly I hope -- if I find resolution) and made some code changes. I rebuilt the solution, re-packaged the WSP file. Removed the existing solution and deployed the new one.
Same behavior.. ok, I'm not an expert developer so sometimes I have to take a couple stabs at something to fix code. I did this several times over several hours... beginning to get frustrated I searched for a few clues online regarding adding/removing entries to the web.config. I found some great information in the following blogs/articles:
https://msdn.microsoft.com/en-us/library/bb861909(v=office.14).aspx
https://msdn.microsoft.com/en-us/library/ms467128.aspx
https://sharepointlive.blogspot.com/2009/02/how-to-add-or-remove-appsettings.html
However, no matter what I tried nothing worked. At some point I decided to modify the entries that were being written to the event viewer. Basically I added a ton of output so that I could see exactly where the code was failing. Much to my surprise I found that the event entries did not change....this is where the head-banging started. And, no, I'm not a heavy metal fan.. I was literally banging my head on the desk.
I referred to Steve Peschka's blog above regarding the timer service and I began resetting IIS and stop/starting the sptimerv4 service in between deployments, but still no relief. As a last ditch effort I decided to close my PowerShell window and open a new window.. Voila! On the next code deployment the event log entries were now reflecting my changes/additions.
Explanation:
I'm no PowerShell expert, but it appears that PowerShell keeps the original WSP cached and fails to load the new file even though it has changed since the last loading of the file. By closing and opening a new window I was forcing PowerShell to load the WSP from disk.
Where am I now? ... well, I'm still battling the original problem that I started working on... adding/removing entries from the web.config. I have the adding part down.. but the removal is where I'm stuck. Hopefully I'll have a resolution soon and when I figure out what I'm doing incorrectly I will write it up if it's not too obvious.
Comments
- Anonymous
February 17, 2011
Good to know! - Anonymous
February 21, 2011
Did you already find a solution for this instead of using a new PowerShell session?I have the same problem as you, that PowerShell is caching SOMETHING and I just don't know how to clear that cache. In my particular case I am installing a WSP, which provisions site templates. All is fine in the Central Administration (i.e. I can create a new site with my site template) - but in PowerShell the site templates are nowhere to be seen. Open a new session of powershell --> all is fine, site templates exist. - Anonymous
February 23, 2011
Unfortuantely, moontear, I have not... I'm asking around today on this very topic.. I found your posts in the social forums this morning while researching what I thought was another PS caching issue. I'll update as I find out more. - Anonymous
June 27, 2013
Did you find out. thanks - Anonymous
June 27, 2013
Daniel I never found out any additional details around the PS caching, sorry. What I do as a consequence is that I either open a new PS session or I am sure to reload or refresh any of the objects that I'm working with ..