I was working on a custom site definition for SharePoint 2010, specifically I was messing around in the ONET.XML with web part placement. I had changed the layout of a page and needed to move my web parts to different zones. So I changed the WebPartZoneID attribute as usual, but I could not get it to work. My web parts were being inserted into the same old zone as before. I gave up eventually and thought I'd solve it another day.
Today after a fresh boot, I redeployed my site again and all was working as expected. Huh?
The way I was working the other day was that I had a PowerShell command line session open and I was simply issuing two commands to delete and create a new site based on my definition. Sometimes I would use the quick deploy method from CKSDEV and sometimes I would do a full deployement between these commands:
Remove-SPSite http://myintranet New-SPSite http://myintranet -OwnerAlias XCOMPLICA\Joe -Template XCOMPLICA#0Regardless of what I did however, the New-SPSite command never picked up any changes I made to the ONET.XML file. I have now confirmed with a few more tests that I need to start up a new Powershell console for this to happen. I even tried iisreset and resetting all the app pools of SharePoint - no difference. It's cached somewhere in the cmdlet.
I guess I am putting my commands in a script I can call from a batch file, or maybe I'll try doing something with Powershell scopes to resolve this.
In any case beware of this caching, it cost me half a day.