Avoiding Deployment Issues with Visual Studio Sharepoint Workflows from Source Control

 Twitter |  Facebook |  digg it |   delicious |   LinkedIn 

By: Justin Botchek

There are a couple headache inducing issues that I wish I'd come across the solution for earlier when attempting to load and deploy a SharePoint workflow with code stored in source control.  If you open the solution and immediately attempt to deploy, the first error you will get is "Value cannot be null.  Parameter name: uriString." 

The answer seems obvious once you realize what Visual Studio is trying to tell you, but it wasn't immediately apparent to me from the error message the first time I came across it.

Normally when you create a new workflow project in visual studio you will be prompted to specify a local site to use for debugging along with the name of the workflow.  When loading a project from source control however, that step doesn't get completed.  

To fix this error all you need to do is look for the "Target Site" property of your workflow solution. Clicking the button that appears when you highlight this field will bring up the new workflow dialog box that allows you to configure the local site, associated lists, and trigger options. 

The second deployment issue you may eventually run into is an Access is Denied error when Visual Studio attempts to copy the workflow and feature xml files to your SharePoint installation.

This happens if the workflow is deployed without first checking out the feature and workflow xml files.  The read only attribute of the files in source control is applied to the files in your features folder, preventing further deployments.  Deleting the existing files from the features folder and ensuring they are both checked out in source control will prevent the issue from reoccurring.  It only takes a few instances of having to delete them manually before you'll remember to check out everything.