If you deploy a workflow and you change it while you still have workflows that are still running using the old version, you will get an error when those workflows try to re-load. To avoid this, you will need to use workflow versioning.
With workflow versioning, you sign the workflow assembly and you indicate the location of each version in the web.config file of the IWebWF site.
This tutorial uses the Vacation Request 2.0 workflow as an example. Obtain the source version of the Vacation Request 2.0 workflow project and open it in Visual Studio 2008 (or higher). You will also need to obtain the source version of the IWebCore project from http://IWebWF.com.
In Visual Studio 2008, right-click on the VacationRequest project in the Solution Explorer and select Properties.
In the Properties page, select the Signing tab (on the left hand side) and on the Signing page, check the Sign the assembly box, and select New... from the drop-down.
In the Create Strong Name Key box, enter StrongName.snk for Key file name. You may choose to enter a password, if so see this link for the process. Click the OK button.
You will now see a StrongName.snk file in the Solution Explorer.
All referenced assemblies to a strong named project must also have strong names. The VacationRequest project references the IWebCore assembly so it will need to now have a strong name.
Download the latest version of the IWebCore project source from the http://IWebWF.com site and give it a strong name. You will then need to attach the IWebCore project to the solution, then have the VacationRequest project and the IWebWF website reference this project.
Also note the SampleWorkflow workflow will no longer work because it was compiled against a non strong named version of the IWebCore project. You can download a complete working solution here: IWebWeb.zip
Right-click on the solution in the Solution Explorer and choose Build Solution.
Ensure that the IWebWF site has the current version of the IWebCore.dll and VacationRequest.dll in it's "Bin" directory. You will have to delete the IWebCore.dll that comes with the install version of IWebWF and make sure the version from the referenced IWebCore project is built into the "Bin" directory.
Log into the DotNetNuke website and start a workflow.
When you log into the IWebWF administration, you will see the workflow.
When you click on the workflow GUID you will see the details of the workflow.
Create a folder named Version_1_0_0_0 and move the VacationRequest.dll to it.
Locate the sn.exe tool (usually at C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin).
Place a copy of the sn.exe tool and the VacationRequest.dll file in the same directory (For example C:\temp) and run the following from the command line (open the command line by clicking on the Windows Start button then choosing Run then enter cmd then click OK):
sn -T VacationRequest.dll
The public key token will be displayed.
Open the web.config file in the IWebWF site and add a new node to the runtime section (at the bottom of the web.config file):
<dependentAssembly> <assemblyIdentity name="VacationRequest" Culture="neutral" publicKeyToken="[ENTER YOUR PUBLIC KEY TOKEN FROM THE PREVIOUS STEP]" /> <codeBase version="1.0.0.0" href="bin\Version_1_0_0_0\VacationRequest.dll"/> </dependentAssembly>
When you click on the GUID in the IWebWF administration, the details will still show.
In Visual Studio, in the Solution Explorer, right-click on the VacationRequest project and select Properties. On the Properties page, click the Application tab and then the Assembly Information button. Change the Assembly Version to 2.0.0.0 and Click the OK button.
Build the solution in Visual Studio and create a new vacation request in the DotNetNuke website.
When you click on the GUID in the IWebWF administration you will not get an error for either workflow even though they are running using different versions.
However if you try to approve a request made with a previous version of the workflow you will get an error.
This article explains the problem:
However the solution will not work in this case because we are not manually loading the workflows
The solution is to separate the project for the IVacationRequest interface.
Delete the IVacationRequest.cs file from the VacationRequest project.
Create a IVacationRequest project with a single code file named VacationRequest.cs with the following code:
using System;
namespace VacationRequest
{
public interface IVacationRequest
{
Guid StartWorkflow(int parmRecordID, int parmCheckDigit, string parmWebService,
string parmAdministratorEmailstring, string parmEmployeeEmail);
bool ApproveRequest(int parmRecordID, int parmCheckDigit, bool parmApproval);
}
}
Give the IVacationRequest project a strong name and reference it in the VacationRequest project.
In the VacationRequest project, change the workflow version back to 1.0.0.0 and rebuild the solution.
Remove the VacationRequest.dll file from the Version_1_0_0_0 directory of the "Bin" directory in the IWebWF website.
There should now only be a single VacationRequest.dll file in the "Bin" directory (the 1.0.0.0 version you just built).
Notice there is now a IVacationRequest.dll in the "Bin" directory in the IWebWF website.
Create a request in the DotNetNuke website.
You will now be able to approve the requests even though they are using different workflows.
Basically you can version workflows that use assemblies if:
You can download a complete working solution here: IWebWeb.zip
[Back to: The ADefWebserver DotNetNuke HELP WebSite]
DotNetNuke™
is a registered trademark of DotNetNuke Corporation.