Windows Workflow

Wintellect Blog

Paul Mehner — Tue, 07 Aug 2007 02:32:21 GMT

I'll cross post for awhile to this blog; however, I'm now also posting on the Wintellect blog site at http://www.wintellect.com/cs/blogs

A Tale Of The Unhandled Workflow Exception

Paul Mehner — Tue, 07 Aug 2007 02:30:46 GMT

Workflow Foundation (WF) catches the unhandled exceptions of any workflow instance that it’s charged with running. Upon catching the unhandled exception of a workflow instance, WF terminates it and raises a WorkflowTerminated event where it generously includes the exception in the event arguments. At first glance this seemed like a reasonable approach. After all, one doesn’t want a sloppy and poorly crafted workflow taking down an entire service and jettisoning hundreds of other smoothly executing workflows. <tears> Unfortunately my initial enthusiasm was soon dampened by a series of conversations with Jeffrey Richter. Jeffrey convinced me that my initial thoughts were dead wrong, and that the design chosen by the WF team is inherently deficient in this area. </tears>

The basic problem boils down to this: WF isn’t impervious to the perils of unhandled exceptions any more than other managed code that we write. The fact that we’ve placed the WF runtime in charge of managing multiple workflows doesn’t excuse it from this priority rule; to the contrary, it would seem to exacerbate the problem. The fact that the runtime runs all of workflow instances in its own AppDomain seems to seal the deal. At the end of the day, workflows are compiled and executed as machine instructions under the management and control of the CLR. An unhandled exception to a workflow is exactly the same as an unhandled exception to a C# program. The perils of catching all unhandled exceptions are well known and can be found in Jeffrey’s CLR via C# book and many other sources, so they aren’t repeated here.

It would seem then that the only choice available to the WF team to have written a more resilient workflow runtime then would have been to have created a separate AppDomain for each workflow instance so that AppDomains with unhandled exceptions could be terminated without impacting other workflows or the WF runtime. This leaves me feeling slightly nauseas because the performance implications of adding this level of overhead would have undoubtedly been (dare I say) very noticeable; however, I can think of no other option with managed code to deal with unhandled exceptions and still play-by-the-rules. While I was no “fly-on-the-wall” when WF was being designed, I can well imagine that the workflow team was forced to choose performance over the other harder-to-measure and easier-to-brush-under-the-carpet objectives. And that is the end of tonight’s tale of the unhandled workflow exception.

Windows Workflow Foundation BRE Does Not Update Value Type Fields of a Structure

Paul Mehner — Mon, 29 Jan 2007 13:22:00 GMT

The Business Rules Engine of Windows Workflow Foundation does not appear to update value type fields that are part of a structure. When the THEN action of a rule is executed and a calculation updates a value type in a struct, the value of the structure member remains zero. Turning on tracing of the execution of individual business rules shows successful execution of the assignments, but the targeted field maintains its initial value of zero during its use in subsequent calculations. No exceptions are thrown and tipping the BRE via the "update()" command has no impact on this behavior. In my case, changing the struct to a class cured the BRE of this ailment.

Console Hosted Windows Workflows Hang With TestRunner

Paul Mehner — Tue, 20 Jun 2006 04:14:00 GMT

It appears that console hosted Windows Workflow applications hang and CPU usage climbs to 100% when executing the CreateWorkflow method from program.cs when Mailframe's Testrunner is installed on the same machine. Testrunner is a Visual Studio add-in that integrates running NUnit tests and provides test performance and coverage metrics (good when a project's unit tests were previously written with NUnit, or you don't have or wish to purchase a VSTS license). Removing Testrunner seems to fully resolve this problem.

WinFX Becomes .NET Framework 3.0

Paul Mehner — Sat, 10 Jun 2006 08:55:00 GMT

Microsoft Corporate V.P. Developer Division Soma Somasegar announced today on his blog that the WinFX name will be officially changed to .NET Framework 3.0. Windows Workflow Foundation will also be a part of the .NET 3.0 Framework.