The Visual Studio Development Environment

Visual Studio is the epicenter of workflow development. It provides virtually all the tools and functionality required to develop all kinds of workflow-related software. In the past, Visual Studio was generally used for traditional software development - namely, writing code. However, in the past few years, Microsoft has made Visual Studio the place for seemingly all types of development on its platform. The following products utilize Visual Studio for development purposes: BizTalk, SQL Server Analysis Services, Integration Services, and other SQL Server products, as well as the more traditional items, such as ASP.NET and Windows Forms.

The major advantage of utilizing Visual Studio across so many products is consistency. There are many concepts specific to the Visual Studio development environment that can be carried across technologies. Microsoft has applied this idea to other products as well - the Office system is a great example. Back in the day, many software applications, even from the same vendor, had dissimilar user interfaces. The Office suite of applications has long since standardized interfaces so that they are consistent across the board. The idea is that after the user becomes comfortable with Word or Access, learning Excel is much easier.

Solutions and Projects

To facilitate the logical grouping of items in your development effort, Visual Studio provides the concepts of solutions and projects. A solution is the overall container of all items; therefore, you can have only one solution open in an instance of Visual Studio. A solution can contain one or more projects and other ancillary solution items. These solution items can be items such as text documents, images, assemblies to reference in projects, or any other supporting items aside from code.

A project represents one .NET assembly and has one of the following project output types:

• Windows Application

• Console Application

• Class Library

The Windows and Console Application project output types generate an .exe file, whereas the Class Library project output type generates a .dll file.

Creating New Solutions and Projects

Creating new solutions and projects is easy, and you have a couple of options for starting a new workflow development effort. To create a new project within a solution by default, which is one of the more common methods, open Visual Studio and select File New Project from the main menu. The New Project dialog box is displayed (see Figure 4-2). To access the workflow project templates (discussed in the next section), select the Workflow option from the tree control under your desired language.

Figure 4-2

Give your new project a name and a location. If you want Visual Studio to create a separate directory for the solution, select the corresponding option. Click OK, and your new solution and project are created and loaded into the Visual Studio environment.

You also have the option of creating an empty solution first and then adding one or more projects to it. To do this, select the Other Project Types Visual Studio Solutions option from the New Project dialog box and then select Blank Solution from the right side of the screen. You can use this method to maintain complete control over where and how your solutions and projects are created.

You can add new projects to an existing solution from the Solution Explorer window in Visual Studio. Right-click the solution and select Add New Project from the context menu. This displays the same New Project dialog box shown in Figure 4-2.

Workflow Project Types

By default, the Workflow Extensions for Visual Studio provide six project templates that contain default files related to each project type and automatic references to key workflow-related assemblies.

Sequential Workflow Console Application

A project created from this template has the Console Application output type and provides you with two files initially: Program.cs and Workflow1.cs.

Program.cs contains a class called Program, which contains a method with the signature static void Main(string[] args). This is the standard entry point method signature for a classic console application.

Workflow1.cs is a sequential workflow generated with the code-only workflow development model. You would generally not use this development mode manually, because Visual Studio is responsible for the code that defines properties and adds activities to the workflow.

The Workflow1.cs code file does not contain the code that is generated automatically for adding activities, wiring event handlers, and the like; rather, Visual Studio creates another code file called Workflow1 .designer.cs. Figure 4-3 shows these two files in the Visual Studio Solution Explorer window.

Figure 4-3

The Workflow1.designer.cs file contains a partial class that corresponds to the Workflow1 class in Workflow1.cs. This keeps the generated code out of your way when you’re working in the Workflow1.cs file. The following code shows the contents of a Workflow1.designer.cs file. The workflow corresponding to this code contains an IfElse activity with two branches.

  partial class Workflow1 {    #region Designer generated code    /// <summary>    /// Required method for Designer support - do not modify    /// the contents of this method with the code editor.    /// </summary>    [System.Diagnostics.DebuggerNonUserCode]    private void InitializeComponent()    {       this.CanModifyActivities = true;       System.Workflow.Activities.CodeCondition codecondition1 =          new System.Workflow.Activities.CodeCondition();       this.ifElseBranchActivity2 =          new System.Workflow.Activities.IfElseBranchActivity();       this.ifElseBranchActivity1 =          new System.Workflow.Activities.IfElseBranchActivity();       this.ifElseActivity1 = new System.Workflow.Activities.IfElseActivity();       //       // ifElseBranchActivity2       //       this.ifElseBranchActivity2.Name = "ifElseBranchActivity2";       //       // ifElseBranchActivity1       //       codecondition1.Condition +=          new System.EventHandler<System.Workflow.Activities.ConditionalEventArgs>(             this.MyCondition);       this.ifElseBranchActivity1.Condition = codecondition1;       this.ifElseBranchActivity1.Name = "ifElseBranchActivity1";       //       // ifElseActivity1       //       this.ifElseActivity1.Activities.Add(this.ifElseBranchActivity1);       this.ifElseActivity1.Activities.Add(this.ifElseBranchActivity2);       this.ifElseActivity1.Name = "ifElseActivity1";       //       // Workflow1       //       this.Activities.Add(this.ifElseActivity1);       this.Name = "Workflow1";       this.CanModifyActivities = false;    }    #endregion    private IfElseBranchActivity ifElseBranchActivity2;    private IfElseBranchActivity ifElseBranchActivity1;    private IfElseActivity ifElseActivity1; } 

By letting Visual Studio manage this code, you can more easily perform the specified activities - setting properties in the Properties window and dragging and dropping them visually.

Sequential Workflow Library

This project template is similar to the Console Activity project output type except that it is not executable. The project’s output type is Class Library, which enables you to start a collection of workflows without having to develop a host.

The only files added to this project by default are Workflow1.cs and Workflow1.designer.cs.

Workflow Activity Library

The Activity Library project template provides you with a starting point for a set of custom workflow activities. The project’s output type is Class Library.

The only default files in the project are Activity1.cs and Activity1.designer.cs. Just as with the code-only workflows, all designer-related properties are contained in the Activity1.designer.cs file.

State-Machine Workflow Console Application

This project template is very similar to the Sequential Workflow Console Application project template. By default, the project contains Program.cs, the workflow host, and the workflow files Workflow1.cs and Workflow1.designer.cs.

The only difference in this project template is that Workflow1 is a state-machine workflow rather than a sequential workflow.

State Machine Workflow Library

The State Machine Workflow Library project template is similar to the Sequential Workflow Library project template, except this template contains a state-machine workflow by default rather than a sequential workflow.

Empty Workflow Project

This project template is what it sounds like - an empty project. The only advantage it has over creating a standard class library project is that the references to workflow assemblies are added by default.

Although this template doesn’t give you much by default, it gives you complete flexibility out of the gate.

Menus

Several menu items in Visual Studio provide functionality related specifically to Windows Workflow Foundation development.

The Workflow Menu

This menu provides workflow-specific activities in Visual Studio (see Figure 4-4).

Figure 4-4

The Save As Image option enables you to take a snapshot of a workflow in its current state and save it as various different image types, such as a bitmap or JPEG. You can use this to validate workflow functionality with others in your organization through e-mail or some other medium, or for documentation purposes. The Copy to Clipboard option is similar, except that instead of saving the image, it copies it to your computer’s clipboard.

The Generate Handlers option is another time-saving option. It automatically generates event handler methods for the currently selected item’s events. This works for activities and the workflow itself.

You can select various workflow views when designing a workflow in Visual Studio. You then navigate these views in the Workflow menu. As you can see in Figure 4-4, the current workflow has three views: the SequentialWorkflow, Cancel Handler, and Fault Handler views. (The various views for each workflow type are discussed later in this chapter.)

The Create New Theme and Select Custom Theme options are related to workflow designer themes, which are discussed later in this chapter. You use the Zoom and Navigation Tools menu options to visually manipulate the workflow designer. The last option in this menu, Debug, enables you to set debugging options for your workflow. (Debugging is discussed later in this chapter.)

The Project Menu

Although the Project menu is not specific to Windows Workflow Foundation, it does have some context-specific items related to workflow development. As you can see in Figure 4-5, you can add several workflow-related items to your current project.

Figure 4-5

The Workflow Toolbar

The workflow toolbar provides zooming, workflow navigation, and themes options (see Figure 4-6).

Figure 4-6

These workflow toolbar options are also available from the Workflow menu in the main menu.

The Toolbox

The Visual Studio Toolbox provides you with all the components necessary for developing workflows. The Toolbox drag-and-drop functionality enables you to visually build your application. Figure 4-7 shows the Toolbox with all out-of-the-box Windows Workflow Foundation activities.

Figure 4-7

Displaying Custom Components in the Toolbox

In addition to displaying the standard workflow activities, the Toolbox can display custom components that you or others have developed. Visual Studio Toolbox can detect all workflow activities in the current solution. For example, if a project in your current solution contains custom-developed workflow activities, you can set it up so that these activities are automatically displayed in the Toolbox (see Figure 4-8).

Figure 4-8

To enable this Toolbox functionality, all you need to do is to decorate your activity class with ToolboxItemAttribute. For example:

  [ToolboxItemAttribute(typeof(ActivityToolboxItem))] public class MyCustomActivity : Activity 

Adding Items to the Toolbox

You can also add items that are located in external assemblies to the Toolbox. In addition, you can logically group Toolbox components in tabs. To add a new tab, right-click an empty area of the Toolbox and select Add Tab from the context menu. Then give the tab a name.

At this point, you can add external components to your newly created tab. Right-click an empty area in your new tab and select the Choose Items option. This displays the Choose Toolbox Items dialog box, where you can select the components you want to add to the Toolbox (see Figure 4-9).

Figure 4-9

This dialog box contains the following tabs:

• NET Framework Components - This tab shows .NET assemblies that are currently in the Global Assembly Cache and their status related to whether or not they have been added to the Toolbox.

• COM Components - This tab does not pertain to workflow development.

• Activities - This tab is specifically related to Windows Workflow Foundation and shows all activities that have been added to the Global Assembly Cache. The items on this tab are a subset of the .NET Framework Components tab.

You can either select an item from the .NET Framework Components or Activities tab or click the Browse button to locate a .NET assembly on the filesystem. After you select an assembly that contains custom activities, they appear in the list and are selected by default. You can modify your selection using the corresponding check boxes and click OK. The custom activities that you selected appear in your new Toolbox tab, and you can use them in workflows.

This dialog box also contains a filtering text box that allows you to type a few letters of the item you are looking for to display only matching items.

Project Item Types

There are several item types that are specific to a Windows Workflow Foundation project. To add these items to your project, you can use the Project menu (discussed earlier), or right-click your project and use the context menu. To provide easy access to common items, the context menu enables you to add the items by selecting the Add from the Project context menu. This displays the Add submenu (see Figure 4-10).

Figure 4-10

If you select the New Item option from the Add submenu, you are presented with a long list of available project items. The Add New Item dialog box is shown in Figure 4-11.

Figure 4-11

The items displayed on your machine may differ based on the installation options of Visual Studio. This dialog box allows you to add new items such as sequential and state workflows using the different development modes discussed earlier in this chapter as well as new activities.

The Properties Window

The Properties window enables you to manipulate values and settings on various items in Visual Studio. If you have used Visual Studio for development in the past, you are already very familiar with this window. However, because this window is so important to Windows Workflow Foundation, it is described briefly here.

The Properties window displays properties in a context-specific manner related to what is selected in the Visual Studio document region. For example, if you select the workflow designer by clicking a blank area of the workflow, the Properties window displays the corresponding property names and descriptions (see Figure 4-12).

Figure 4-12

The Properties window also allows you to configure event handlers related to the item that is currently selected. To access the item’s events, click the lightning-bolt icon. The events view of the Properties window is displayed, as shown in Figure 4-13.

Figure 4-13

As you can see in Figures 4-12 and 4-13, there are some context-sensitive links that enable you to perform actions on the currently selected item. In these figures, the selected item is a sequential workflow, and the items are related to generating event handlers and navigating to the different workflow views.

The bottom of the Properties window shows the description of the currently selected property or event.

The Designers

You will probably spend the majority of your workflow development time using the workflow designers. The designers are located in the document region of Visual Studio, and you drag and drop activities to and from them to build your workflows. Each workflow type has its own designer and specific features. In addition, you can visually develop and modify activities with a designer.

The designers enable you to do things like comment individual activities by right-clicking and selecting the Disable option from the context menu. After you have disabled an activity, it appears with a green, slightly opaque overlay.

The designers also have various views that represent different areas of development for that workflow or activity. The following sections discuss each designer view with its respective parent.

Sequential Workflows

The sequential workflow designer enables you to visually design ordered workflows by dragging and dropping graphical activities and manipulating their properties.

The sequential workflow designer has three different views that separate distinct areas of functionality for the workflow. You can navigate to these views by using the icons in the lower-left corner of the workflow designer or by using the drop-down menu. To display the drop-down menu, hover over the Sequential Workflow title at the top of the designer and click the down arrow.

The Workflow View

The workflow view is what you are probably most used to and is the default view for the sequential workflow designer. If you are currently in another view, you can return to the default workflow view by using the icons at the bottom left of the workflow designer (see Figure 4-14). The leftmost icon moves you to the workflow view.

Figure 4-14

The Cancellation Handler View

The cancellation handler view enables you to define a set of activities that occur when a workflow instance is cancelled. This view automatically contains the CancellationHandler activity, which must to exist and cannot be removed. The default view of the CancellationHandler was shown in Figure 4-14.

This view executes and behaves no differently from the main workflow designer view. You drop activities into it that you want to occur if the workflow is canceled.

The Faults View

The faults view of the sequential workflow designer is analogous to a try-catch block in any CLR language. The following code represents a standard exception-handling block in C#. Here, code that may cause an exception is wrapped in a try block. Then several catch blocks are defined in order to monitor for specific exception types. The order in which catch blocks are defined is important, so you should place more specific exceptions types at the top of the chain and more generic exception types at the bottom.

  try {    // below is some potentially dangerous code    ... } catch(SqlException ex) {    // handle the SQL exception } catch(InvalidOperationException ex) {    // this is a more generic catch block } catch {    // this catch block will catch anything missed so far in the chain } 

The workflow fault handler view follows the same logic as try-catch blocks. You add FaultHandler activities to the FaultHandlers activity in order, from left to right, to monitor for specific fault types. You map each added FaultHandler activity to an exception type, along with its own flow of other activities in the area below the fault types list. (Chapter 12 discusses fault handling in more detail.)

Figure 4-15 shows the sequential workflow’s faults view for a fault handler that catches a SqlException.

Figure 4-15

State-Machine Workflows

State-machine workflows have two views within the Visual Studio designer. You use the workflow development view (Figure 4-16) to define the states that exist in a state-machine workflow and the events that occur in each. You use the EventDriven activities view to define a flow of work whenever a configured event is raised (see Figure 4-17).

Figure 4-16

Figure 4-17

For more information about state-machine workflows, see Chapter 10.

Activities

In addition to developing the two workflow types visually, you can visually create standalone activities. A Sequence activity enables you to define a set of activities to form a reusable workflow. The activity designer has the following three views, which are the same as the sequential workflow designer views:

• Activity view (analogous to the sequential workflow view of a sequential workflow)

• Cancel handler view

• Faults view

Figure 4-18 shows the default view for the activity designer.

Figure 4-18

Chapter 6 covers activity development, including this type of visual sequence activity development.

Design-Time Validation

Activities can have built-in validation logic, which enables Visual Studio to check for configuration errors at design time. This means you do not have to wait until compilation or even runtime to find errors in your activities.

Each activity can determine if it is configured correctly. The workflow designer can also determine each activity’s status. Workflow activities that do not pass validation are flagged with a red exclamation point, as shown in Figure 4-19. Clicking this exclamation point displays a drop-down menu with details about what is causing the problem. In the case of the Code activity shown in the figure, the ExecuteCode event needs to be wired.

Figure 4-19

The steps required to implement this type of validation behavior in custom activities are covered in Chapter 6.

Themes

Because the visual aspect of workflow development is key to this platform, the Windows Workflow Foundation team has provided an extensible architecture that enables you to customize how workflows look and feel.

Visual Studio provides the Theme Customization dialog box, which allows you to view and modify a properties for different workflow activities. You can access this dialog box by clicking the Create New Theme button on the workflow toolbar or by selecting the Workflow Create New Theme in Visual Studio. Figure 4-20 shows the Theme Customization dialog box displaying the properties for the IfElse activity. As you can see, there are properties such as Background Start Color and Background End Color that allow gradient color schemes for activities.

Figure 4-20

If you make modifications to the default workflow activity themes, you have the option of saving your changes to a .wtm file. Doing this generates an XML file that defines the colors, images, and other options that you specified for your theme. You can load existing themes into the Visual Studio environment by clicking the Select Custom Theme button on the workflow toolbar or from the Workflow main menu.

Debugging

Although debugging strategies are covered in Chapter 12, it is important to point out that Visual Studio plays a vital role in this process.

Debugging workflows in Visual Studio is very similar to debugging traditional code. You can place breakpoints on workflow activities by right-clicking and selecting Breakpoint Insert Breakpoint from the activity’s context menu. Standard commands such as Step Into, Step Over, and Start Debugging provide you with a consistent debugging experience. This includes the ability to configure workflow variables as watch variables so that their values can be monitored during execution.

The Type Browser

The Type Browser dialog box enables you to select .NET interfaces for the CallExternalMethod and HandleExternalEvent data-exchange activities. To access this dialog box, click the ellipsis button on the InterfaceType property of either of these activities.

The dialog box scans the current project for any interfaces decorated with the ExternalDataExchange attribute and displays them to the user. In addition, the user has the option of pointing to another assembly outside the project. All interfaces decorated with the same attribute are displayed from the assembly (see Figure 4-21).

Figure 4-21

In addition, you can use the Type Browser to add FaultHandler activities to a FaultHandlers activity. Each FaultHandler activity corresponds to .NET exception class through its FaultType property. If you click the ellipsis button on this property in the Properties window, the Type Browser dialog box displays the classes that inherit from the base System.Exception class.