Just now I was trying to debug a Workflow Service in WF4, that a colleague of mine had created. Strange thing was, even though I set a breakpoint the debugger didn’t stop, it just returned the answer as if I wasn’t debugging at all. In the same projects, I have other Workflow Services, and I hade no problem debugging those (except that debugging workflows is slooow, but that’s beside the point).
I started looking a the Debug output, when this line caught my eye:
“C:\TFS\..” – hey, that’s not were I keep my project files! We, of course, use a source code repository for our code (TFS, actually), and every developer checks out the project to a location of his or her discretion. I, for example, use “C:\@Projects” as the root folder. My colleague, let’s call her Inger, because that’s her name, uses “C:\TFS". But how would the debugger know that, and try to use her structure, just because she created the file, you might wonder.
So did I. A little investigation came up with this. In the Xamlx file for the Workflow Service, right at the top, I found this little nugget:
Yes, it is true. WF4 keep the physical location of the Workflow Service Xamlx in an attribute called sad:XamlDebuggerXmlReader.Filename in the Xamlx file itself! Naturally, my first instinct was just to remove the the sad:XamlDebuggerXmlReader.Filename attribute. No luck, debugging didn’t work at all. So I changed the attribute to point to my file, in “C:\@Projects”. And behold – debugging works.
What the were you thinking, Microsoft? Do you actually believe that every developer on a project has the same physical structure on their machines? Or do you think that there is always only one developer on a WF4 project? Do you think it’s a good idea that we have to remember to change the sad:XamlDebuggerXmlReader.Filename attribute every time we need to debug a Workflow Service?
All workflows and no play makes Johan a dull boy. But actually, I think I’ll write a tutorial to Workflow Foundation 4 soon. I’ll call it “how to actually use it”.