Part 2 of 3 – Deploying our InfoPath VS Workflow Project

Hopefully you’ve walked through Nick Swan’s previous article and successfully created your InfoPath 2007 forms and the Visual Studio project needed to create our simple sequential worklow. Now we need to set about deploying it. First let’s look at feaure.xml in DeploymentFiles\FeatureFiles. Copy and paste the following xml into that file:


Here you can change the name of your workflow Title and Description. It would also be a good idea to generate your own guid id and add it as the Feature Id.
The next file we need to look at is workflow.xml. Copy and paste the following xml into that file.


Again you are free to change the title and description attibutes here, and also again it’s best to generate your own guid id for the id attribute. The code beside class is the fully qualified name of your workflow class, eg namespace.classname. The CodeBesideAssembly is made up of the name of your dll (you can often take this as being the project name), the assembly version which is set in the Properties\AssemblyInfo.cs file. To get the public key value of our assembly we need to open a Visual Studio 2005 Command Prompt. This can be found via the start menu by going Start -> Program Files -> Visual Studio 2005 -> Visual Studio tools -> Visual Studio 2005 Command Prompt
In the command prompt type : sn -T “”path to your workflow dll””
The only other parts you need to worry about for this workflow are the formURN’s. These are used to identify exactly which InfoPath form should be used at each point. You can find these values by opening your published InfoPath 2007 forms in design mode (right click on them in explorer and chose design), then from the main menu go File -> Properties, and the value will be in the ID field:
We are only going to build and deploy our workflow in debug mode so we don’t need to worry about the files in the Production Folder.

When we do a Re-Build of our solution the PostBuildActions.bat file will be executed.
The template PostBuildActions batch file will need to be configured to cope specifically with your Cheshire Council Council Virtual development environment. 
Firstly, the script will need to be edited to ensure the urlhttp://mycheshireteamslocal:24001 is present in place ofhttp://localhost.      Also, add –force to the deactivating and uninstall script so it reads:
%STSADM% -o deactivatefeature -filename %PROJECTNAME%\feature.xml -urlhttp://mycheshireteamslocal:24001 -forceThe GACUTIL script operates from drive e:\ on Virtual Development Images.  The path to the gacutl files will need to be amended to point to the relevant location as follows:
IF EXIST “”E:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe”” (SET GACUTIL=””E:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe”” & GOTO DEPLOY)
IF EXIST “”E:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe”” (SET GACUTIL=””E:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe””) ELSE (ECHO Gacutil.exe could not be found! & GOTO QUIT)
From a new project however in the post build actions of the project a
parameter of NODEPLOY is passed to it so our workflow feature is not deploy. To change it so our workflow is deployed do the following steps:
 Right click on your workflow project and chose PropertiesSelect the Build Events tab from the project properties screen.In the textbox for the “”Post-build event command line:”” the last parameter of the line will be NODEPLOY. Change this to simply DEPLOY
And that is it. To build and deploy our solution simply rebuild it. Generally this can be done by pressing F6 or going Build -> Rebuild Solution from the main menu.
You should get something similar to the following text in the output window. If you get an errors detailed here hopefully there should also be a hint of how to fix it. Something else to check before trying to bind your new workflow to a document library is that the correct files have been deployed to the 12 hive. Look in ..\12\TEMPLATE\FEATURES\ – or whatever you called your workflow and you should see feature.xml, workflow.xml, DemoInitiation.xsn and TaskEdit.xsn.
If the deploy seemed to run ok and you have all the files in your Feature folder, go and try your workflow out! Good luck!
I hope all the above makes sense. In the net blog posting i’ll explain how to test out your newly deployed workflow feature.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s