0

I've got a WF feature which I've been deploying into my development/test environment fairly frequently, and as such have run into an issue where the assembly seems to be cached by the SharePoint Timer service (SPTimerV3), and then an out-of-date version is used after the workflow rehydrates following a Delay Activity.

To fix this, I've tried adding a "NET STOP SPTimerV3" and "NET START SPTimerV3" to my batch file after the STSADM commands to install the .WSP . It works to restart the timer service, and I no longer have the caching problem, however restarting the timer this way seems to kill my SP App Pools in IIS fairly regularly.

Has anyone found a good way to restart the timer in a WSP deployment batch file without adverse affects? Do I need to restart another dependent service, or restart the App Pools each time as well?

DaveD
  • 2,196
  • 1
  • 23
  • 33
  • This is not exactly a programming question and I think you are more likely to get on answer if you post this question on http://sharepoint.stackexchange.com/. – Marek Grzenkowicz Sep 13 '11 at 12:34
  • Well, it's relevant to the scripting in a batch file ;) Honestly though thanks for the comment and I'd love to post it there, but currently cannot for corporate internet blocking issues... Hoping for the best here. – DaveD Sep 13 '11 at 12:36

1 Answers1

0

you need to restart IIS as well. IISRESET /noforce should do the trick.

brian brinley
  • 2,364
  • 1
  • 13
  • 10
  • 1
    Works now with the basic pattern of: (1) Remove old WSP (2) Restart SPTimerV3 (3) Install new WSP (4) IISReset – DaveD Sep 13 '11 at 14:07