Authoring Workflows

<< ASP.NET Event Validation and “Invalid Callback Or Postback Argument” : Part II | Home | Recreational Debugging >>

Authoring Workflows

My latest OdeToCode article, Authoring Workflows, looks at how XAML, XOML, partial classes, and compilers all work together in Windows Workflow.

I appreciate any comments, suggestions, and other feedback about the article.

Print | posted @ Monday, March 27, 2006 1:41 AM

Comments on this entry:

# re: Authoring Worflows

by scott at 3/27/2006 3:18 AM

Rob caught one XAML/WPF bug in the sample code. Copy and paste error - corrected.

# re: Authoring Workflows

by Brian J. at 4/19/2006 12:09 AM

Is this purely for Windows apps or can this be applied to asp.net apps? I'm going to have to go through it with a little bit better attention to the particulars, but I'm interested in really understanding more about this.

Thanks.

# re: Authoring Workflows

by scott at 4/19/2006 3:18 AM

Brian:

WinWF will work in ASP.NET also. There are a few samples out there if you search.

# re: Authoring Workflows

by William at 4/20/2006 9:47 PM

Can you give some quick advice. We are a C++ shop. We do have a lot of C++ code. I am trying to avoid C#. C++/CLI is very powerful. My look at VS 2005 with WinWF shows that C# is the only thing support when using the designer. I want the designer. W/o it, it will be very difficult to maintain complex state machine type workflows that I believe would benefit us. Is there a way until you get full C++ support, to do a code seperation type thing and keep the designer, but, have code in C++? Thanks.

# re: Authoring Workflows

by Scott at 4/21/2006 2:06 PM

William: I think the best thing to do is ask on the MSDN Workflow forums. Some of the WinWF product managers hang out there and might give some insight as to support for other languages. (Of course, any .NET language can use WinWF and create workflows, it's just a question of how well the language will integrate in the IDE / designer).

# re: Authoring Workflows

by Andy Hochstetler at 6/9/2006 5:01 PM

Fantastic info on WF! Aside from the orange book are you aware of any other decent reference info that gets to this level of detail? Thanks!!!

# re: Authoring Workflows

by Scott at 6/9/2006 7:10 PM

Andy:

As far as I know, the orange book is the only material in print for WF. There are 3 or 4 WF books due out this fall.

There are a lot of good webcasts on WF. Look around the resources of windowsworkflow.net.

# re: Authoring Workflows

by Nathan at 10/9/2006 7:56 PM

What a fantastic article. I usually don't comment on these kinds of things, but lately almost every time I go to research some just-below-the-surface aspect of these emerging .NET/MS technologies Google sends me to OdeToCode where I find an incredibly useful, clear and concise writeup of just the subtlety I needed to understand. Personally, I can't imagine how people like you manage to learn and apply all of this new technology and still have time to give back to the community, but however it happens, it is tremendously enabling, so thank you.

# re: Authoring Workflows

by Scott at 10/10/2006 2:14 AM

Thanks, Nathan. I *really* appreciate the kind feedback.

# re: Authoring Workflows

by Grigoriy Milman at 2/11/2010 8:15 PM

We need to run different version of the code-based workflows without closing application.

Our workflows are packet in assembly, for example, WorkflowSet.dll. Here we have a workflow Workflow1:
public sealed partial class Workflow1: SequentialWorkflowActivity
{…
}

We can create workflow instance:

Assembly workflowAssembly = Assembly.LoadFrom(“WorkflowSet.dll”);
Type workflowType = workflowAssembly.GetType(“Workflow1”);
WorkflowRuntime workflowRuntime = new WorkflowRuntime();
WorkflowInstance instance = workflowRuntime.CreateWorkflow(workflowType);
instance.Start();

Question. How to reload assembly contaning the workflow? We can stop runtime engine but we can’t unload assembly holding our workflow type.

# re: Authoring Workflows

by Scott Allen at 2/12/2010 7:45 AM

You might want to do something similar to ASP.NET and shadow copies assemblies so they aren't locked. You could also load into a different app domain so you could unload.