Importing SharePoint Designer Workflows Into Visual Studio (Part 2)

In Part 1 of this post, I discussed the general issues my team has run into importing SharePoint Designer 2010 (SPD) workflows (WFs) into Visual Studio 2010 (VS). But for a quick overview: I am currently part of a hybrid team of SharePoint designers and SharePoint developers, and in order to make our application deployment one hundred percent automated, we wanted to import all of the WFs created via SPD into VS. I made the assumption that the "Import Reusable Workflow" VS project import was the winning ticket. But instead, it was more like a speeding ticket, and, to string along this weak metaphor, I was incarcerated for over two months for driving without insurance.

Our solution was to call Microsoft and task for help. The details of this conversation, specifically the issues we discovered and the questions we asked will comprise this post. Since that discussion and the ensuing ninety percent solution (not one hundred percent, since one show-stopping issue still didn't work) were so long, I'm going to break the latter into a Part 3. I'll be going into detail about the problems we faced with the workflow; specifically, the ones that we determined were not just bugs on our end, but rather nuances with SPD, and what we were left with after a "successful" import into VS.

Interestingly, most of these problems are SPD- specific, and it's possible that the hacks employed to get around them are part of the issue causing VS not to import them correctly. But these were only discovered after augmenting our development approaches to support VS integration. I'll present these first, and then move on to the specific problems we encountered when actually performing the import, or experienced after deploying from VS.

SharePoint Designer Issues

You'll see below that a lot of the SPD questions we posed to Microsoft regarded InfoPath (IP) forms and associated custom content types used for the WF tasks. We created these content types, which inherit from WorkflowTask, to store additional data in our task lists. (All of our WFs use the out-of-the-box "Workflow Tasks" list for each sub site.) The IP forms provide the UI for the users to populate this data.

<Rant>

IP was the cause of many other headaches suffered by our WF designer. Why SPD, in 2010, forces these as the default over ASPX pages, I'll never understand.

</Rant>

Problem Statement #1: For custom task forms, we are unable to set the content type of the task form via SPD (the field is read only). This requires us to do have to manually hack the XMOL and CONFIG files for the WF:

Question #1: How do we properly set the content type for a custom InfoPath (IP) task form?

Problem Statement #2: Another area we have to manually hack the XOML file is configuring the WF to check in/out the current list item. Here's all that's available to us in the UI for check in/out actions:

Question #2: How do we configure an SPD WF step to check out the current list item?

Problem Statement #3: On WFs with custom IP task forms, after solution gallery deployment and activation, we are running into an issue with opening SPD and globally publishing the WFs. Here's what we see in SPD (in the "Forms" section) on the server we just deployed to:

This is actually fine for the association / initialization forms, as those can be auto-generated. However, we have to make customizations to the task form, and those changes will be lost if we have to delete the IP form so SPD can re-gen it. In this case, IP gives me the following message:

In any case, I do a "Quick Publish" operation in IP, and return to SPD. Publishing still fails with that first message above. However, if I close SPD first and then reopen it, the forms appear to know they've been updated via an IP Quick Publish (notice the parentheticals next to the form names now say "custom form" instead of "* needs update").

But when I Publish Globally now, it still fails with the same message. "[name of task form].xsn (custom form)" above changes to "[name of task form].xsn * (needs update)."

But this is the one we can delete and have SPD re-generate! Doing so and globally republishing does work, but the customizations of the task form are lost.

Question #3: How do we fix customized IP task forms (deployed successfully via WSPs in the site collection solutions gallery) so that their customizations are not reset by the "Publish Globally" process?

Problem Statement #4: We have found that every time you WSP-deploy a workflow created from SPD to a new environment via our procedure, folders will be created on the target environment under "All Files\Workflows" that correspond to every workflow that's ever been created in the development environment. In other others, if I have Workflow1 and Workflow2 in my local environment and I WSP-deploy Workflow2 only to my development server, an empty folder will be created under "All Files\Workflows\Workflow1" even though it WASN'T WSP-deployed. Although this is mostly just in the way, if we ever do deploy Workflow1, and forget to delete this extraneous folder, we'll get an error that the folder already exists.

Question #4: Is there any way to get this not to happen?

Question #5: One of our WFs contains a lookup field. After WSP-deploying it to the development environment and opening SPD to globally publish it, we get the following error. This is very indicative of the shortcomings of SPD, since we have carefully deployed our site columns (lookup or otherwise) to ensure they have the same GUIDs across our environments. We could technically work around this issue specifically, but this requires adjustments to our security model and basically re-architecting the WF.

Question #5: How do you get WFs with lookup site columns to be globally-publishable?

Visual Studio Issues

I've combined my VS questions to Microsoft into one narrative:

When using the "Import Reusable Workflow" new project template, the workflows are imported, but the project does not compile. I got past this by adding the proper SharePoint/IP/Office DLL references. However, although I can get it to generate WSP packages, the IP forms are never published; they are actually nowhere to be found on the target environment. After fiddling around with it for two days, I decided to abandon this approach.

Now, when using the "Import SharePoint Solution Package" new project template, the workflow does import, package, and deploy. However, the project is a mess: unwanted content types and site columns are imported, multiple features are created, and depending on the titles used back in SPD, horrendously long file names are generated in the deep folder structure, at times throwing compilation errors due to eclipsing the Windows max path length. But like I said, it *does* deploy and work. We need to perform a hack to get the workflows to be "Globally Published (a la SPD);" otherwise, the features are web-scoped and can only be activated to the root site. Finally, when opening up the XOML file in Visual Studio, the workflow is HUGE; hundreds of activities are created, and they all have those red exclamation marks on them in the VS WF designer. Maintainability-wise, this won't be agreeable to our client.

Additionally, we've come across two situations in which this approach actually fails. First, one of our WSPs refuses to import; the last step in the "Import SharePoint Solution Package" wizard that allows you to choose which assets to import is blank. No files are listed.

Second, some WSPs have TWO workflows in the manifest, and merging them manually through Visual Studio is extremely hacky and doesn't work all the time.

Both of these WSPs are functional in SPD, and were exported using the same process as the rest.

The detailed answers to the SPD questions are out of scope for this post. Of course, hacking the XOML file is not supported. But to my surprise, the issue with the lookup field is not supported either! All in all, the theme of the response was to use VS for "complex" WFs - the subjective answer I discussed in Part 1. As far as explicit SPD support goes, we were toeing the line between what that tool could handle and what VS could do natively. The irony, of course, is that exporting to VS wasn't working either.

So if you take one thing away from these posts, it's this: use SPD for what SPD does well. Because when it works, it works awesome. We only got into trouble when trying to make the tool sweat. Of course, everything has a support list of functionality and a breaking point; we weren't being wanton with SPD in my opinion. Microsoft was very consistent in their guidance, regardless of its subjectivity. So read on to Part 3, and let's see how we were able to get around most of these issues!