>
Blog
Book
Portfolio
Search

12/5/2011

9363 Views // 0 Comments // Not Rated

Resolving Workflow Association Errors Caused By Custom Master Pages

As part of my continuing saga of working with my hybrid Visual Studio "all code" / SharePoint Designer "no code" team, I'd like to discuss, which, compared to part 1 and part 2, turned out to be a small issue. This time workflow is the name of the game. For this project, all workflows were created by our "native creative" folks using SharePoint Designer. The integration point revolved around creating a Visual Studio SharePoint 2010 workflow by way of a new empty workflow project whose template can suck in a WSP exported from a SharePoint Designer reusable workflow and go from there. Phew. Compared to the collaborations described in the previous parts, this one was actually the cleanest.

After generating the workflow project in Visual Studio and tweaking a few things, we could use standard SharePoint 2010 integration to package it into a WSP proper. Not only does this allow the entire team to access our workflow code without having to Email WSPs around, (which would be horribly tragic, being SharePoint professionals and all) but it also gives us the opportunity to get more and more of our project into TFS, allowing code creating in SharePoint Designer to participate in source control, automated builds, and version history.

The issue we ran into, however, wasn't so much a function of the integration, but more so an unfortunate circumstance created by the particular combination of our master page and deploying these workflows via WSP; specifically, the WSP that came from SharePoint Designer, not Visual Studio. This is still significant, however, because what's important is that the workflow was deployed via a solution package, not welded to the site directly via SharePoint Designer.

The problem was that, after associating the workflow with a document library and starting an instance of it with a particular document, whenever clicking the "Next" to go from the generic workflow add page to the specific association page as shown below...

Workflow Add

...we'd get the following error:

Workflow Error

Trolling the ULS logs, two different exceptions matched the correlation token:

System.ArgumentNullException: Value cannot be null. Parameter name: g at System.Guid..ctor(String g) at Microsoft.Office.Workflow.WrkAssocPage.AssociationOnLoad(EventArgs ea) at Microsoft.Office.Workflow.CstWrkflIPPage.OnLoad(EventArgs ea) at System.Web.UI.Control.LoadRecursive() at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

And, more prevalently:

System.Web.UI.ViewStateException: Invalid viewstate. Client IP: 127.0.0.1 Port: 50312 User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) ViewState: /wEWBgLorcSLCQLvn5sfAu6fmx8C/v/6tg4C6f+yrA0Cs8//9g4r+4Aa9cVfyQ53TBQlRsx9AouMvQ== Referer: http://site.local/_layouts/AddWrkfl.aspx?List={A40293A6-58B7-40C3-918C-F854F0609180} Path: /_layouts/CstWrkflIP.aspx

ViewState. Ugh. None of the typical viewstate fixes worked: we weren't dealing with "hard coded" machine keys, and viewstate itself wasn't unexpectedly disabled (or enabled) by any specific controls, pages, or web.config files. It wasn't until my SPD-er elucidated me to the fact that everything worked just fine when using v4.master as the master page. So clearly, something on the mater page didn't like something on the workflow association page. The fix? Dig through all 699 lines of HTML and figure out the offender.

Again: ugh. My approach was to go through and comment out, using SharePoint Designer, the inner HTML of each ContentPlaceholder. Dealing with twenty or so placeholders was less daunting then considering all lines at once, but it still sucked. However, I lucked out: the offender turned out to be an innocent-looking placeholder near the top of the file that contained a single line of code: the DelegateControl that hosts a SmallSearchInputBox. When I commented that delegate turd out, the workflows began to, well, work.

Here's the full HTML of the ContentPlaceholder, in case you are using a common baseline SharePoint publishing master page and therefore might run into this:

Code Listing 1

  1. <asp:ContentPlaceHolder id="ContentPlaceHolder1" runat="server">
  2. <SharePoint:DelegateControl ID="DelegateControl4" runat="server" ControlId="SmallSearchInputBox" Version="4" />
  3. </asp:ContentPlaceHolder>

Like I said, the issue this time wasn't explicitly due to the collaboration between SharePoint Designer and Visual Studio; it was more so caused by doing something Visual Studio-y from an output of SharePoint Designer. So if you get weird errors on your workflow association page while using a custom master page, check this specific line, or other general deviations from v4.master. Not only did I luck out by finding the offending line before losing my mind combing through page after page of SharePoint markup, but it also happened to be functionality that I could do without. We had a custom search UI, and therefore had no need for this delegate control. Of course, if we needed that line, we'd have to figure out how to do hack it or replace it with something that didn't wreak havoc on our workflows.

No Tags

No Files

No Thoughts

Your Thoughts?

You need to login with Twitter to share a Thought on this post.


Loading...