You've made it to Part 3! In Part 1, I described the general situations we faced importing SharePoint Designer 2010 (SPD) Workflows (WF) into Visual Studio 2010 (VS). Part 2 went into a lot of detail about the specific issues we encountered. In this final piece, I'll outline the...are you ready for this...SEVENTY-ONE step procedure that I was given. When the engineer at Microsoft first sent over this document, it was actually only a few very (although extremely convoluted) steps. So I broke them down and distilled the process into something that anyone familiar with VS could follow.
When designing a WF, assign its construction to either VS or SPD in the third place after classifying them as "simple" or "complex" in the second place having defined what each of those terms means to your team and their skillsets in the first place. Then, after the SPD WFs are built and tested, the following procedure gets them into VS, addressing almost all of the concerns listed in Part 2. I'm going to assume you're starting form an existing VS solution.
Let me begin by first defining some placeholders I use in the step-by-step:
Here's what Solution Explorer will look like after an import (I did clean up some of the node names to make it little more intuitive):
And here we go:
The code and markup above was given to me by Microsoft, so use third-hand code at your own risk! But in general, that's it. I mentioned a few times that the one thing that didn't work was using existing content types for our task forms. This was a show-stopper for us, and the only reason we didn't move forward with this procedure. But I hope this outlines what has to be dealt with when exporting "complex" SPD WFs into VS.
And, of course, what has to be dealt with after making assumptions...