Welcome to the final chapter of the book—and I would like to think that we've saved the best for last! Many applications need some form of configuration or customization capability, and traditionally this was done by adding in some form of hook to the application so that a third party could add in extra code. A common method was to define an interface in .NET and then ensure that each plug-in supported that interface. The only trouble with this is that it's all code based, and users without a programming background would find this daunting, if not impossible, to do.
Another way to extend applications is using some form of scripting language—such as VBA (Visual Basic for Applications), which is included in Microsoft Word, Excel, and many other applications. The issue here is the barrier to entry—there are licensing costs for VBA, and integrating it with your application isn't a trivial task.
In .NET 3.0 and above there is another—and in my opinion much better—way to permit end users to customize an application: Windows Workflow Foundation (referred to as WF throughout the rest of this chapter).
A workflow can be considered simply as a function in C#, which consists of a number of statements (known as activities), optional parameters, and optional return values. That, however, is where the similarity ends—a workflow is defined using a set of graphical building blocks, rather than code.
Activities are the building blocks from which a workflow is ...