Windows Workflow Foundation 4.0 (Part 2 The Designer)

In part two of this series we’ll look at the project types available in Visual Studio 2010 and take look at the feature changes in the workflow designer.

Project Templates

There have been a number of changes in the available projects between WWF 3.5 and WWF 4.0. Below is a screen shot of the Visual Studio 2008 new Workflow project dialog.

As you can see in addition to the empty workflow project, there are several variations of the Sequential workflow and the State machine workflow. These variations include SharePoint 2007, library and console workflow applications. All of these workflows are built on designer functionality that has been available in Visual Studio since Visual Studio .Net was released in 2002.

The Visual Studio 2010 new Workflow project dialog contains a lot less clutter, some new project types and some that are missing. There may potentially be more project types available upon release, but for now we’ll concentrate on what’s available in beta 1. Below is a screen shot of the Visual Studio 2010 new Workflow project dialog.

The projects listed in the new project dialog are Activity Designer Library, Activity Library, Flowchart workflow console application and the Sequential workflow console application. All of the projects in the dialog are new for workflow with the exception of the Sequential workflow, missing is the State Machine workflow. All of the workflows in the WWF 4.0 are based on xaml or extensible markup language. This is the same technology that is used in WPF and Silverlight just to name a few.


Here is a quick overview of the project templates that are available in Visual Studio 2010.

The Activity Designer Library template provides a way to create a user interface for a custom or standard activity.

The Activity Library template provides a way to create custom activities visually.

The Sequential template creates a workflow that executes activities in sequence, one after another.

The Flowchart template creates a workflow that executes activities one after another, but allows the flow to return to an earlier step. This template replaces the State Machine workflow and is much more flexible.

Workflow Designers

There is a visual difference between the new Workflow designer and the Visual Studio 2008 designer. Below is the Visual Studio 2008 designer for a sequential workflow.

Below is the Visual Studio 2010 designer with a sequential workflow opened up.

The Visual Studio 2010 designer has some noticeable changes from the previous designer in that now, rather than creating variables and arguments in code, the designer now provides facilities for creating them from the designer.

When defining arguments from the argument window, you provide a name, type, default value and a direction. Valid directions are In, Out, In/Out and property. We’ll discuss these later after we discuss the available Out of the box activities and start to build a work flow.

Variables are much like arguments in definition except that instead of defining the direction we define the scope of the variable.

Navigation to activities and child activities is provided via bread crumbs. This was a feature of the State Machine workflows in WWF 3.5 that has carried over into WWF 4.0. The bread crumb navigation makes it easy to drill into the activities in a workflow to set the properties.

Overall the Workflow designer in Visual Studio 2010 is an evolution of the designer in Visual Studio 2008. Variable and Argument dialogs go a long way toward reducing the coding chores. And bread crumb navigation makes moving within activities and child activities a breeze. In the Next part we’ll look at the huge list of Out of the box activities.

Windows Workflow Foundation 4.0 (Part 1)

Windows Workflow Foundation (WWF) has undergone a radical face lift in the .Net 4.0 framework. This face lift includes new out of the box activities, the designer, workflow types and persistence to name a few of the changes.

  WWF was first released as part of the .Net 3.0 framework and version 2 was released with the .Net 3.5 framework. While most successful among ISV’s (Independent Software Vendors), it hasn’t really taken hold with enterprise. WWF 4.0 is intended to change that and make a core part of every developers toolbox much like the way WCF has become the defacto communications technology in the .Net framework.

As with any beta release, documentation is nearly non existent. So with that in mind I’m going to break this down into a series of articles on WWF 4.0, learning what’s new and sharing my discoveries along the way.

Over the next several articles I intend to cover a lot of ground. I’ll spend time discovering and discussing the following topics

• Designer changes – What’s new in the designer
• Workflow types – New workflow types and what’s gone
• Out of the Box Activities – New activities and what they provide
• Custom Activities = How to create custom activities in WWF 4.0
• Workflow Activation – Activating workflows from ASP.Net and Windows applications
• Hosting – The new “Dublin” IIS hosting capabilities
• Persistence – The WWF 4.0 persistence model

Entity Framework V2 and POCO

There is a rally good series of post at the ADO.Net team blog covering POCO (Plain Old CLR Objects). They cover enhancements such as Lazy loading, Change Tracking and best practices.

If you’re planning to use the Entity Framework or poking around at the beta, this series provides some good background and guidance.

VS 2010 MVC 1.1

The latest update for ASP.Net MVC  is available here for Visual Studio 2010 beta 1.

The App that cried wolf

We’ve all read the story about the little boy who cried wolf. Time and again he cried wolf and one day when there was a real wolf no one listened.

Applications that send emails for error after error are a lot like the boy in the story. At first we investigate each error and try to come up with corrective measures to eliminate the issue, but eventually we just create a junk mail filter and simply ignore them.

So what is the root cause of the wolf app? The primary cause lies in how we define and handle exceptions. Exceptions are just that, exceptional cases that we hadn’t specifically planned for. We know during design and implementation that the potential exists for an exception. For example we may read a file and that file may be corrupt.   But the way that it is usually handled is by throwing it up the chain and eventually the whole app screeches to a halt and the spam machine kicks into overdrive.

Since we already know the potential for an exception exists in a particular piece of code, we should handle it where it happens and degrade gracefully. Additionally not every error or exception should be the subject of an email. Errors should be classified and dealt with accordingly. For many errors this means logging to a file or a database for later review. Many times the logs will show a pattern of problematic methods that continually raise the same errors. These can then be prioritized for rework during a maintenance cycle. Critical errors on the other hand should be identified by an email or an entry in the application event log. These critical errors should be dealt with immediately because the have a direct correlation to the up time of the application.

By taking some time to plan and design the way in which errors and exceptions are dealt with could mean the difference between delivering an app that cries wolf or one that matures of the course of time.

Blog coding

I’ve recently noticed a new trend in coding that I find troublesome. I’ll call it Blog Coding. Blog coding is a condition where programmer X doesn’t know how to implement a certain technology or needs to solve a real or perceived issue, searches for answers by typing phrases in (insert your favorite search engine) and then spending hours reading through the results.

More often than not the code found in blogs is designed to solve a particular problem the author has encountered in his/her domain and may only provide a partial solution to the problem faced by the blog coder. Even more common, the samples are text book style code snippets that really don’t apply to real world issues at all. But the blog coder will diligently work with various samples and snippets combining code from multiple blogs to create a Frankenstein solution. The solution may or may not work or it may work on the blog coders local machine. When confronted for an explanation of how the code works or why it was written a certain way (you can always spot blog coder code by the variation in coding styles present in single methods or classes).

So how do we as developers help eliminate blog coding? The first and most important thing to do is to encourage fellow programmers take the time to learn the tools and frameworks that we work with. Managers should insure learning time is set aside during the work week. Write some code! Nothing is better for learning than writing some real working code. If all else fails, post a question on a programming specific Q&A site like Stackoverflow.