If you are building Windows Workflow Foundation (WF) applications today (and you aren't building Sharepoint Workflows) you should be using WorkflowServiceHost for your hosting environment. Period, end of discussion (oh - well we can have more decision about it - but its a fait accomplis at this point). Especially if you are using WF to implement a service, using .NET 3.5 is a total no brainer. I was doing so the other day using a StateMachineWorkflow hosted in IIS and I was getting an exception. The exception (which I found after I attached the debugger to IIS) was the dreaded (and pretty common) exception "QueueNotFound for queue X". Now - if I was writing the hosting layer myself I would handle the WorkflowRuntime.WorkflowIdled event and introspect on the WorkflowInstance using WorkflowInstance.GetWorkflowQueueData method to see what queues where available at different points during the workflow to help figure out what the problem was. The problem was that I expected the Queue to be there at that paritcular point of execution, and I wanted to verify that fact using the WorkflowInstance.GetWorkflowQueueData method like this: void WorkflowRuntime_WorkflowIdled( object sender, System.Workflow.Runtime.WorkflowEventArgs e) { ReadOnlyCollection<WorkflowQueueInfo> queues; queues = e.WorkflowInstance.GetWorkflowQueueData(); foreach (WorkflowQueueInfo qi in queues) { Debug.WriteLine( "QueueName : " + qi.QueueName); foreach ( string actName in qi.SubscribedActivityNames) { Debug.WriteLine(
Read More...