Tip: Regularily reset SharePoint Timer Service during development

Thursday, 31 October 2013

There is an interesting issue that can occur on development machines during development of SharePoint solutions that contain Site Templates or list templates in certain scenarios when site creation is not done manually, but using some kind of Custom Timer Job. The issue manifests in a way that even after retraction of old WSP and deployment of new WSP, even after performing IISRESET, sites created with new WSP don't have applied latest changes which are part of new WSP, but instead use (contain) functionality which is a part of the old WSP. That can give us (developers) lots of hard time causing that development process takes much more time than initially planned, as we cannot see latest changes in the new sites which we constantly create to verify that new functionality is properly applied in the Site Template or List Template.

The resolution of that issue points to one possible explanation. Resolution of the issue would be to follow simple process during deployment, adding additional two steps in the deployment process. Essentially, we need to restart SharePoint Timer service twice before creation of new sites (even once could be enough, but as a precaution I recommend that you do it twice). In my deployment process, I usually retract solutions from within Visual Studio, but deploy them using PowerShell. So, the process would be as follows:

  1. Retract and remove old WSP of your solution

  2. Restart SharePoint Timer Service on your development server (net stop sptimerv4; net start sptimerv4)

  3. Deploy new WSP of your solution

  4. Restart SharePoint Timer Service on your development server

  5. Create new sites (using your customized creation process, for example with custom Timer Job)

Explanation of the issue above that I can connect the dots on (without any reference to official documentation that I know of, or I don't read enough) as suggested by commenter Roman, some resources that explain the issue are as follows

1. KB http://support.microsoft.com/kb/2027455 2. http://alexangas.com/blog/2009/07/debugging-file-locking-in-the-gac/

 SharePoint Timer Service has "cached" old binaries which it uses for creation of new sites, even after those old binaries are not existing on the server file system. The binaries will be replaced with new binaries when the Timer Service is recycled. By forcing restart of SharePoint Timer Service we are basically ensuring that on new start the Timer Service picks up new binaries of our solution (which we are currently trying to develop/debug.