For some reason a lot of people seem to think that only a single WorkflowRuntime object can be created in an AppDomain. And it isn’t just the average Joe out there who seems to think so, no even book authors describe this behavior as the Workflow Foundation book I am reading now does so.
Just to set the record straight I will shout this out once more:
You can have multiple WorkflowRuntime objects in a single .NET AppDomain
Now I know where this perception comes from and its the original beta of Workflow Foundation way back before .NET 3.0 was released. Back then the WF team decided that only a single WorkflowRuntime would be enough for an AppDomain and created this restriction. I am not sure if they actually had a requirement or not but when people objected they listened and lifted the restriction.
The removal of this restriction is a good thing as multiple WorkflowRuntime objects can be useful. The main reason is that different workflow’s can have different, and conflicting, requirements of runtime services. And as a single WorkflowRuntime can have only a single runtime service configuration, and that should never be changed while the WorkflowRuntime is active. For example just think of one workflow that is long running and needs a WorkflowPersistenceService while a second is short running and should never be persisted.