This post is part one of five around SharePoint Designer workflow deployments.
Part Two (no longer applicable)
Part Three (custom task forms: infopath)
Part Four (custom task forms: aspx/ascx)
Part Five (listids)
SharePoint Designer 2010 comes with a lot of improvements around Workflow creation and management, and one of the better new features are Reusable Workflows, allowing Power Users to create and edit workflows that can be used in any site by saving them as templates – which automatically generates a .wsp in order to redeploy these workflows.
However, if you want more control over the generated solution, there aren’t many options, and importing a reusable workflow template into Visual Studio 2010 removes the ability for users to edit those workflows in SharePoint Designer. (I didn’t look too much into this, but I believe it stops being treated as a no-code workflow).
So, after reading this post I found online around packaging the workflows manually, it turns out it’s not too hard to create these wsps yourself.
The main components of the .wsp are:
- A list instance for the Workflow
- A module to deploy the .xoml and associated workflow definition files
- A feature with the same receiver assembly and class used by the SPD generated .wsp
The first step is downloading the workflow files for the workflow you want to package, so you can include it in your solution. The easiest way seems to be to use SharePoint Designer to browse to the correct location and open/save the files, as shown below.
Keeping those files handy, create a new SharePoint project and a new List Instance item. (While you could probably throw this workflow into an existing SharePoint project, it ties your other content and workflow into the same assembly which means when you update the other stuff, it might “upgrade” your workflow and affect existing instances needlessly…)
For your new List Instance, name it Workflows and set the Url to Workflows. Change the Template Type to 117 (the No-Code workflow list), and the feature id to 00bfea71-f600-43f6-a895-40c0de7b0117. The xml should look something like below:
<?xml version="1.0" encoding="utf-8"?>
<Field Name="FileLeafRef">Assessment Task Notification</Field>
(I’m not sure whether the Data Row is required as shown above, but I decided to include it for safety’s sake…)
Once that’s done, create a module to deploy the files you grabbed from SharePoint designer into that list. Your module should end up looking something like below:
<?xml version="1.0" encoding="utf-8"?>
<Module Name="Assessment Task Notification" Url="Workflows/Assessment Task Notification" Path="Assessment Task Notification">
<File Path="Assessment Task Notification.xoml" Url="Assessment Task Notification.xoml" Type="GhostableInLibrary" />
<File Path="Assessment Task Notification.xoml.rules" Url="Assessment Task Notification.xoml.rules" Type="GhostableInLibrary" />
<File Path="Assessment Task Notification.xoml.wfconfig.xml" Url="Assessment Task Notification.xoml.wfconfig.xml" Type="GhostableInLibrary" />
<File Path="Assessment Task Notification.xsn" Url="Assessment Task Notification.xsn" Type="GhostableInLibrary" />
Note that you want the Type to be GhostableInLibrary, and you may have to set the build action for the *.xoml file to None – if you open this up in the Workflow Designer in Visual Studio 2010, you’ll see a whole lot of errors around __Context and other things; you can safely ignore these as they get taken care of by the Feature Receiver.
Speaking of feature receiver, the last thing we need to do is to add it. Open up your feature, and set the following properties for your feature:
Receiver Assembly = “Microsoft.SharePoint, Version=126.96.36.199, Culture=neutral, PublicKeyToken=71e9bce111e9429c”
Receiver Class = “Microsoft.SharePoint.Workflow.SPDeclarativeWorkflowProvisioningFeatureReceiver”
And that’s it! If you deploy your solution from Visual Studio, you should see the workflow come up as being available in SharePoint designer, and be able to edit and publish as per normal. Have fun!