SharePoint Workflow with InfoPath “Specified Form Cannot be found" Issue RESOLUTION

Article
07/21/2010

As another day in the life of SharePoint goes, I found my self in a bit of a pickle. I had built a workflow and wanted to use InfoPath to display the form for each of my tasks in the workflow. I started with the guidance on MSDN with the Walkthrough of how to do this. I followed all the steps in this article all the way to the deployment step. At this point is where the cart kinda gets off the road. The deployments steps are for those building this solution with SharePoint Foundation and not using the new Visual Studio 2010 features that set a bunch of the stuff in this step up already. What I am going to do below is walk you through the steps that are actually needed to get this to work using VS2010 and the SharePoint templates that are a part of VS2010.

So some things the walkthrough gets correct is the fact that you need a feature definition file (feature.xml) and the Workflow definition file. The walkthrough then assumed that you were using the VS WSS Extensions to deploy the solution. It also fails to detail what the Feature.Xml and the workflow definition files should look like.

Step 1 Feature Definition (Feature.xml)

<Feature xmlns=" https://schemas.microsoft.com/sharepoint/ " Title="MyCustom Request Center Workflows"
Description=""
Id="cc670ffe-fb03-4eb2-8f74-0a70be5cf102"
ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver"
Scope="Site">

<Properties>

    <Property Key="GloballyAvailable" Value="true" />

    <Property Key="RegisterForms" Value="HardwareRequest\*.xsn" />

</Properties>

<ElementManifests>

    <ElementFile Location="HardwareRequest\ApproverTaskForm.xsn" />

    <ElementManifest Location="Elements.xml" />

    <ElementManifest Location="RequestPreProcessEvntRcvr\Elements.xml" />

</ElementManifests>

</Feature>

Register the Form

The feature definition file for the workflow is very similar to any other SharePoint feature definition. The big key here when using InfoPath for your workflow forms is to make sure that you declare the forms you wish to register for use with your workflow. This is done by adding the following properties to the manifest of the feature:

<Property Key="GloballyAvailable" Value="true" />

<Property Key="RegisterForms" Value="HardwareRequest\*.xsn" />

Note above that the path used in the “Value” of the “RegisterForms” property is a relative path to the feature. This means that your forms need to deployed in the same feature folder as the workflow. When using the VS2010 Workflow Template a folder is created in the project with the name of your workflow. you will want to copy your InfoPath form to this folder. If you have multiple forms or like to keep things organized then you can create a subfolder at this location and place your form there, just make note of the RELATIVE path. SharePoint OOB has a folder called “Forms” which stores the IP Forms for all the OOB workflows.

The other thing to point out here is that you MUST use the following feature reciever for your workflow to register correctly:

ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver"

NOTE: The above assembly are OOB the box with SharePoint and your form will not display correctly if you do not use this feature receiver. Without this I was getting “Specified form cannot be found!” when I tried to perform a workflow action which used my form!

Step 2 Workflow Definition File

<Elements xmlns="https://schemas.microsoft.com/sharepoint/">

<Workflow

Name="Hardware Request"

Description="This workflow will send the request through the hardware request process. This workflow will be for hardware requests only!"

Id="f25f4deb-4be2-4b14-bbee-f4db163cd7bc"

CodeBesideClass="MyCustom.RC.WF.HardwareRequest.HardwareRequest"

CodeBesideAssembly="$assemblyname$"

Title="Hardware Request"

TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"

ModificationUrl="_layouts/ModWrkflIP.aspx">

    <Categories/>

    <MetaData>

      <AssociationCategories>List</AssociationCategories>

      <StatusPageUrl>_layouts/WrkStat.aspx</StatusPageUrl>

      <Task0_FormURN>urn:schemas-microsoft-com:office:infopath:ApproverTaskForm:-myXSD-2010-07-06T02-25-34</Task0_FormURN>

    </MetaData>

</Workflow>

</Elements>

Turns out this file is pretty straight forward and all the MSDN documentation get this one right. Please refer to MSDN for more details on specifying the form for your Association forms, Initiation Forms, and/or Task forms. The key change here is to make sure the TaskContentTypeId is set to the OOB SharePoint InfoPath Workflow Task Content Type:

TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"

The other thing to not here is to make sure you get the URN for your form correct!

Deploy and Debug Fun

At this point you should be ready to go! You should be able to just hit F5 and test your workflow!

Appendix (Quick Troubleshooting Check List)

Below is a quick Troubleshooting check list courtesy of Alexei Levenkov, (You are the man!)

NOTE: Alexei uses the SharePoint 2007 version of the Dll while the examples above use the newer version for SP2010

1. Check how out of box feature for workflows are implemented. Your feature should be pretty close to one that is already there. I.e. look into following folder that contains Expiration workflow:

%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\FEATURES\ExpirationWorkflow

2. Make sure feature ID is unique.

3. Make sure you have <Property Key="GloballyAvailable" Value="true" /> as part of properties in the feature.xml.

4. Make sure you specify one of feature activation callbacks:

4.a) Workflow's callback (recommended) ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver"
4.b) Forms Services callback, supports only files in root folder of the feature.

ReceiverClass="Microsoft.Office.InfoPath.Server.Administration.XsnFeatureReceiver" ReceiverAssembly="Microsoft.Office.InfoPath.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

5. If you use Workflow's feature activation callback (recommended) then make sure you have <Property Key="RegisterForms" Value="Forms\*.xsn" />. Make sure Value points to relative locaiton with XSN files.

6. If you use Forms Services feature activation callback make sure all XSN files are at the root of the feature folder.

7. Extract all assemblies (DLL) from form templates (XSN) and copy DLL next to XSN in the feature folder. (You can rename XSN to CAB to extract files)

8. Makes sure that all XSNs are published for admin deployment. I.e. use stsadm -o verifyformtemplate command.