If you’re creating your own workflows and want to be able to debug into your code using the timer service (OWSTIMER.EXE) deploying your assembly to the GAC won’t normally be enough for the correct symbols to be loaded. This is due to the SharePoint timer service keeping a cached version of the assemblies it uses.
To force the service to refresh the assemblies it uses you need to restart the SharePoint 2010 Timer service from the services snap-in before attaching the debugger.
Alternatively, you could add the following to the post-build event of the project you want to be able to debug:
net stop SPTimerV4
“C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\gacutil” /i “$(TargetPath)” /f
net start SPTimerV4
This will stop the SharePoint timer service, copy the updated assembly to the GAC before restarting the service again.
Where’s the location of the gacutil program? Gacutil comes with version 1 and 1.1 of the .Net framework (not 2 or above) and Visual Studio. So it should be in at least one of these locations:
%windir%\Microsoft.NET\Framework\v1.0.3705\
%windir%\Microsoft.NET\Framework\v1.1.4322\
%programfiles%\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\
%programfiles%\Microsoft SDKs\Windows\v6.0\Bin\
%programfiles%\Microsoft SDKs\Windows\v6.0A\Bin\
%programfiles%\Microsoft SDKs\Windows\v7.0\Bin\
%programfiles%\Microsoft SDKs\Windows\v7.0A\Bin\
For reference, here is the Gacutil MSDN page: http://msdn.microsoft.com/en-us/library/ex0ss12c(VS.80).aspx
Hey Stuart,
A handy tip, especially if you’re using multiple projects since. Makes it easy to build and deploy a single project rather than the whole solution.
One minor adjustment I’d make is to put quotes round the TargetPath variable so that spaces etc can be accommodated.
ie:
net stop SPTimerV4
“C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\gacutil” /i “$(TargetPath)” /f
net start SPTimerV4
Cheers,
Ch.