Recently I've been messing around with the new workflow foundation developed by Microsoft and included in .Net 3.0. It is very cool! It has great design-time support, it's easy to extend with your own custom activities, and it seems to be very well documented.
At first I was a bit put off by the fact that it doesn't include a simple, run-time configuration process. They do give you the ability to host the designer in your application, but it appears that you have to write a lot of code to make that work (I didn't actually try it, but I did glance over the documentation). However, as I thought about it more, it seems that Visual Studio is a great way to reconfigure the workflow. It might be a bit of overkill for a non-technical person who just wants to reconfigure one or two of the activities, however, if they just go to the workflow designer, it seems pretty easy to use (but what would I know, I'm a developer :). On the other hand, if somebody that is more technically inclined wants to extend the workflow with code, they can do that easily as well.
If you are new to Windows Workflow, I think a build system is a great starter project. It's simple (as far as workflow is concerned anyway), it fits into the workflow concept very well, and it will make your build process easier to configure and extend (if your build process is anything like our current one, as long as it's working, the last thing anybody wants to do is touch it). Even if you don't use it for the build process for the entire product, it can make many tasks that you have to perform on a regular basis on your computer easier (such as preparing your machine for a new build).
Before you can start building a workflow, you will need to install .Net 3.0 as well as Visual Studio 2005 extensions for .NET Framework 3.0 (Windows Workflow Foundation). This will provide the necessary pieces that Visual Studio needs to create workflows.
For the build system I'm creating at work, I created a Workflow Activity Library (a project template available in the New Project dialog) that contains most of the activities that I want to use, such as GetFromVSS, CopyFiles, RenameFile, AttachDatabase, RunSQL, etc. Each activity has one or more properties that allow it to be configured (for example, RenameFile has a property for the path to the file and another property for the new name of the file). As you can tell, these are just building blocks for a build system. For the build itself, I create a Sequential Workflow Console Application (this is a new project type installed with the VS 2005 workflow extensions). If you have several different types of builds (such as a developer build, test build, and production build), you can create a separate project for each one.
So what makes Windows Workflow such a great tool for a build system? Other than making configuration easy, you can also disable activities. This is very useful, especially when testing. There are several parts to the build system that I'm working on (for example, compiling the code and building the database), each one is made up of several activities. I can simply create an activity that contains all the activities for that part of the build and, if I don't want to run it, I can simply click on the parent activity and set it's Enabled property to False.
The diagram below shows a very simple workflow diagram in the Visual Studio Workflow designer. It includes two activities, one of the activities has been disabled. As you can see, the Workflow designer is very similar to the WinForm designer. You start by picking the activity that you want to run from the toolbox (on the left) and dragging it onto the workflow. The workflow will show you the places that you are allowed to drop the new activity. Once you drop an activity onto the workflow, you can set the properties associated with it using the property window (on the right).
If there is interest, I might be willing to write a more detailed article for Code Project that includes sample code. So if you want to read more, make sure you leave a comment.