You are viewing limited content. For full access, please sign in.

Question

Question

Most efficient way to test different builds of custom Workflow activities?

asked on March 27

I have been dabbling in creating a custom workflow activity and was wondering what the most efficient way to test and retest is? What I have currently found that works is after I rebuild the .dll file, that I need to delete the activity in the Workflow Designer Toolbox, delete the reference in the loaded assemblies in the Workflow Designer Toolbox, delete the custom activity in the Workflow Administration Console, restart the Workflow Server service, and then delete the actual .dll file. Then do all that in reverse for the new file.

Is there a better way to test a new build of the .dll file?

0 0

Answer

SELECTED ANSWER
replied on March 28

Blake,

My development cycle on a new custom workflow activity is to build the new version of the DLL, stop the workflow service, copy the new DLL over the old DLL, then restart the workflow service.  Workflow then loads the new version of the DLL and you can proceed to test against it.

The only thing to look out for is if you add or remove any properties from your custom workflow activity between builds.  The designer will throw an error if you open a published workflow that contains a reference to the old activity because it can't deserialize the properties correctly.  The workflow will open but you will have to delete the old activity and insert a new copy of the activity to allow the designer to properly render the new properties.

You are welcome to PM me if you have specific questions.

0 0
replied on March 30

That is how we develop new activities as well. New properties are added with default values as to not break already published workflows. Properties are never removed so older versions can still be loaded by running instances. 

1 0

Replies

You are not allowed to reply in this post.
You are not allowed to follow up in this post.

Sign in to reply to this post.