I've recently started learning Workflow Foundation in conjunction with Sharepoint Server 2007. One particularly annoying issue I have with it is the development setup needed: its kinda designed to only work on Windows Server 2003. What I mean by this is that some sdks don't install at all on other OSes (like the OfficeServerSDK or the Windows SharePoint Services 3.0 Tools: Visual Studio Extensions), while others do install, they even install the Sharepoint workflow project templates in Visual Studio, but they don't deploy any of the needed .dlls you have to reference in those very same project templates (Windows Sharepoint Server SDK).
So what's a developer (that's not running Windows Server 2003) to do? Check out the following article for instructions on how to set up your regular, non WS2003, machine so that you can develop workflows for SPS on it: http://zgud.spaces.live.com/blog/cns!76596824C4119...
Ok, so after reading the above mentioned article and following its instructions you're all set and can develop workflows "locally". Then you deploy them to the "remote" Sharepoint machine and run them. Here basically one of two things happens: a) they run. b) they don't :)
In case of b), and presuming that everything is deployed correctly, but there is an error in the actual workflow code, you have several options:
- check out the Sharepoint log files, located at "%Program Files%\Common Files\Microsoft Shared\web server extensions\12\LOGS". You can usually start from the last file backwards and look for words like "workflow".
- instrument the workflow so that it records some nice messages to the history list. While this is fine, you can't get too verbose with these messages and you definitely can't get too specialized. Still, if you really really want to go this way I suppose you can do some try/catch -es and log the exceptions to the history list, strictly during development. Anyway, this is a poor man's substitute for real debugging.
- actually debug the running workflow
The last option, of course, should only be used against a testing server, not real production environments, but is definitely the most powerful of the three. So how do you do it? Well, after googling around and finding nothing (although, to be honest I found this blog entry which, somewhere in the comments, states that remote debugging against Sharepoint workflows isn't supported; which is not true :)) I dug a little bit and came up with the following lists:
Prerequisites:
- Visual Studio .Net 2005 installed on the remote machine (as documented here)
- Workflow Foundation extensions for VS2005 installed on the remote machine
- Windows Sharepoint Server SDK installed on the remote machine
- Remote debugging monitor running on the remote machine
Steps:
- Build your workflow solution and copy the needed deployment files to the remote machine
- Deploy the files in the needed folders and gac. Make sure to include in the gac ALSO any additional assemblies (like custom activities) PLUS ALL the .pdb files you need (the install.bat file which you get for Sharepoint project templates deploys by default only the main assembly)
- Run iisreset
- From the local machine, VS2005 -> Debug -> Attach To Process
- Make sure you select "Attach to Workflow Code"
- Choose the remote machine's name (or IP address), and the appropriate w3wp process.
- Run the workflow on the SPS remote machine and watch your breakpoints get hit.
In conclusion I must say that although you can do the stuff above, I also realize that given the nature of the prerequisites needed on the remote machine, you might as well just copy your project over there and debug there locally. This is, of course, ok, as long as you don't run into any other annoyance factors, like no source control on the remote machine, remote user connections limit etc.