Jul
18
Written by:
Keith Pijanowski
7/18/2008 12:49 PM
Using Visual Studio 2008 to Create Workflow Foundation Projects
This post introduces Visual Studio 2008 and shows how to use it as a tool for building workflows that utilize Windows Workflow Foundation (a component of the .NET Framework 3.0 and 3.5). I’ll start by describing the history of Visual Studio and the .NET Framework. Then I’ll introduce the workflow project templates and workflow items that Visual Studio 2008 provides for building workflows.If you have built components with Visual Studio in the past, but have not had the chance to explore Workflow Foundation, then this post will introduce you to the new project templates and new workflow items that have been added to Visual Studio for constructing workflows. However, no prior knowledge of Visual Studio or the .NET Framework is assumed. If your preferred development platform is something other than Visual Studio and the .NET Framework then you should be able to follow along. I will also draw a few comparisons between .Net Framework /Visual Studio and Java/Eclipse for educational purposes.
In my previous post on Windows Workflow Foundation (WF) I answered the question “What is Windows Workflow Foundation?” During this post I was very careful how I used the term “workflow” when describing the capabilities of WF. This is because the conventional definition of the word workflow states that it is just a model or a visual depiction of a real world business process. WF also uses the word workflow to refer to its visual depictions of business processes. However a workflow in WF is much more than just a visual depiction. It is a first class software artifact which is compiled into a component that automates business processes. In this post I will use the word workflow to refer to WF models because that is the term the WF documentation uses to refer to its models.
A Brief History of Visual Studio .NET and the .NET Framework
Visual Studio is the user interface that developers use to build components that utilize the .NET Framework. Visual Studio 2008 is the fourth version of Visual Studio since the release of the first version in 2002. Figure 1 shows the versions of Visual Studio that have been released since 2002 as well as their corresponding versions of the .NET Framework.
Are you new to .NET development?
The Microsoft .NET Framework is a software component that is a part of all Microsoft operating systems released since the year 2002. It can be used for building applications that run on Windows Desktops, Windows Servers, Windows Mobile Devices and Embedded Devices. The .NET Framework has a large library of reusable solutions to common programming problems. This library is known as the Framework Class Library (FCL). The .NET Framework also has a runtime that manages the execution of programs written specifically for the .NET Framework. This runtime is known as the Common Language Runtime (CLR).
The Framework Class Library (FCL) provides the fundamental building blocks for any application you may be developing - be it a workflow, web application, desktop application or a library of your own. Its purpose is to provide ready to use utilities for a large number of common functions. File reading and writing, rendering graphics, database interaction, and XML document manipulation are examples of utilities that can be found in the base class libraries. Classes that provide these capabilities are found in namespaces that begin with the prefix “System” or the prefix “Microsoft”.
When a developer compiles code in Visual Studio the result is not native code which can be directly executed. Rather Intermediate Language code (IL) is produced. At runtime the Common Language Runtime (CLR) compiles this intermediate language code into native code which can then be executed. This is done in a “just in time” fashion. In addition to compiling IL code to native code the CLR is also responsible for memory management, thread management, exception handling, garbage collection, and security.
Comparing the .NET Framework to J2EE and JSE
The .NET Framework is a blanket term used to refer to the combination of the Framework Class Library and the Common Language Runtime. The Framework Class Library (FCL) provides functionality that is comparable to the APIs found in the Java Standard Edition (JSE) and the Java Platform Enterprise Edition (Java EE). Finally, the Common Language Runtime (CLR) provides similar features as the Java Virtual Machine.
|
Version
|
Framework version
|
|
Visual Studio 2002
|
.NET 1.0
|
|
Visual Studio 2003
|
.NET 1.1
|
|
Visual Studio 2005
|
.NET 2.0
|
|
Visual Studio 2005 plus extensions for WCF, WPF, and WF
|
.NET 3.0
|
|
Visual Studio 2008
|
.NET 3.5, .NET 3.0, .NET 2.0
|
Figure 1 – Versions of Visual Studio and the .NET Framework
Typically a new version of Visual Studio is delivered for each new version of the .NET Framework. However, as can be seen from the table above the .NET Framework 3.0 was an exception. When this version of the framework was released a new version of Visual Studio was not created; rather extensions to Visual Studio 2005 were released.
Another import fact to note regarding the relationship between Visual Studio and the .NET Framework is that prior to Visual Studio 2008 each version of Visual Studio only had built in support for only one version of the .NET Framework. For example, if you needed to write a Windows application that ran on desktops that had only .NET 1.1 then the easiest thing to do was to use Visual Studio 2003. On the other hand if you needed to write a component for desktops that had only .NET 2.0 then Visual Studio 2005 was the best tool for development. Things got tricky if you wanted to write one component that ran on both .NET 1.1 and .NET 2.0. Targeting two versions of the framework could be done by setting up your configuration file correctly. Unfortunately, if two versions of the framework were targeted then it was the job of the developer to make sure that she only used APIs that were common to both versions of the framework. This is a common scenario for desktop environments and caused developers a lot of headaches.
Visual Studio 2008 provides a feature known as multi-targeting. When a project is created the developer specifies which version of the .NET Framework will be the target for the new component. Developers can choose either .NET 2.0, .NET 3.0, or .NET 3.5. This option can be seen in the upper right hand corner of Figure 3 below. While the new component is being developed only capabilities that exist in the specified version of the framework will be displayed by Visual Studio 2008. Additionally, .NET 3.0 and .NET 3.5 were additive releases – meaning that they are both just .NET 2.0 plus some extra components. Therefore if you build a component for .NET 2.0 it will run on an environment setup for .NET 3.0 or .NET 3.5. Unfortunately there is no support for multi-targeting with the .NET 1.0 and .NET 1.1 because the Framework Class Libraries and the Common Language Runtimes are very different in these versions of the framework.
Multi-targeting is important for workflow development because Workflow Foundation was introduced in .NET 3.0. Therefore if you specify .NET 2.0 as your target then you will not see any WF project types. .NET 3.5 did not introduce a lot of changes to WF. The most significant change was added support for interacting with web services implemented with Windows Communication Foundation. Therefore, if you specify .NET 3.0 as your target then you will not see the new tools that provide support for Windows Communication Foundation. Figure 2 below shows the high level architecture of the .NET Framework 3.5.
Are you new to .NET development?
Windows Communication Foundation (WCF) was introduced in .NET 3.0. It provides a programming model that unifies the various programming models for distributed computing. For example, previous versions of the .NET Framework had separate APIs for SOAP-based communications (ASP.NET Web Services), binary-optimized communications (.NET Remoting), transactional communications (Enterprise Services), and asynchronous communications (MSMQ). WCF unifies these capabilities into a single API for distributed programming.
Figure 2 – The .NET Framework 3.5 (Click image to download a full size poster from Microsoft’s MSDN site.)
Creating an Empty Visual Studio Solution
To get started building workflows we need to create a Visual Studio Solution. This solution will eventually contain the Workflow Project that will be created in the next section. To create a Visual Studio solution go to the File pull down menu, select New, and then select Project… as shown in Figure 3. Once this is done the dialog shown in Figure 4 will appear.
Figure 3 – Navigating to the New Project Dialog
Figure 4 – Using the New Project Dialog to create an empty solution
In the Project Types section of the dialog expand the Other Project Types node, select Visual Studio Solutions, and select Blank Solution. Give the new solution a name in the lower portion of the dialog and specify a location for the solution. When the OK button is clicked Visual Studio will create a new folder in the location specified using the solution name. For example, once the OK button is clicked in the dialog shown in Figure 4 the following folder will be created: C:\Users\Keith\Documents\Visual Studio 2008\Projects\WF Sandbox. Figure 5 shows the empty Visual Studio solution that will be created once the OK button in Figure 4 is clicked. The next step will be to add a workflow project to this solution.
Are you new to Visual Studio?
A Visual Studio Solution is a way to organize related Visual Studio Projects. A typical Visual Studio Project contains the source code for a component under development. For example if you were building a simple three tiered system you may have a data access component, a business logic component, and a user interface component. The source code for each of these three components would be in its own Visual Studio project and all three projects would be inside one Visual Studio solution.
Comparing Visual Studio and Eclispe
Visual Studio solutions are similar to Eclipse workspaces which are used to contain multiple projects. However, unlike Visual Studio solutions an Eclipse workspace cannot be closed without closing the entire environment since workspaces in Eclipse are also used to hold global environment settings.
Figure 5 – An empty Visual Studio solution named “WF Sandbox”
Creating a Workflow Project
To create a new project inside our Visual Studio solution, right click the solution name in the project explorer. A popup menu will be displayed. This is shown in Figure 6. Select Add from the popup menu, then select New Project … . An alternative to using the popup menu is to use the pull down menus of Visual Studio. If you wish to use the pull down menus of Visual Studio select the File pull down menu, select New and then select Project …
Figure 6 – Creating a new project with pop up menus
Visual Studio allows developers to build many different component types. We are interested in building a workflow so once the New Project dialog is displayed select the Workflow node under the Project Types section of the dialog – this is located in the left portion of the dialog. The dialog will now look like what is shown in Figure 7. This figure shows the new project dialog with the Workflow templates enumerated.
Figure 7 – New Project Dialog for workflows
As can be seen in Figure 7, there are eight project templates that can be used to begin a workflow project. A Visual Studio project template is much like a Word document template or an Excel Spreadsheet template. It represents a starting point for a specific task, i.e., letter, meeting notes, memo, etc. In the case of Visual Studio project templates, each template will make sure that all needed framework assemblies are referenced for the component type that the template represents. (In our case this is a workflow.) The template may also provide a default code file with sample code to help get you going. The table in Figure 8 lists the workflow project templates and their purpose.
Are you new to .NET Development?
An assembly is the unit of deployment when creating components with the .NET Framework. It contains compiled versions of related classes. An assembly can be either a standalone executable or it can be a Dynamic Link Library which is designed to be referenced from either a standalone executable or another dynamic link library. A standalone executable typically has an extension of “.exe”. An example of a standalone executable is a Console Application, a Windows Forms application, or a Windows Presentation Foundation application. Dynamic Link Libraries typically have an extension of “.dll”.
Comparing .NET to Java
An assembly in .NET serves the same purpose as a Java archive file (JAR File). Like a JAR file an assembly is .NET’s unit of deployment which can be versioned. An assembly also has a manifest to describe everything in it. An assembly can be optionally signed giving it a unique identity that can be recognized by others for the purpose of assigning privileges.
|
Template Name
|
Purpose
|
|
Empty Workflow Project
|
Sets up a project that will be compiled into a dynamic link library (dll) assembly and adds references to all the needed .NET Framework assemblies for WF. No sample workflows will be added to the project.
|
|
Sequential Workflow Library
|
Sets up a project that will be compiled into a dynamic link library (dll) assembly and adds references to all the needed .NET Framework assemblies for WF. A sequential workflow is added to the project.
|
|
State Machine Library
|
Sets up a project that will be compiled into a dynamic link library (dll) assembly and adds references to all the needed .NET Framework assemblies for WF. A state machine workflow is added to the project.
|
|
Sequential Workflow Console Application
|
Sets up a console application project and adds references to all the needed .NET Framework assemblies for WF. A sequential workflow will be added to the project. This template is often used for testing purposes.
|
|
State Machine Workflow Console Application
|
Sets up a console application project and adds references to all the needed .NET Framework assemblies for WF. A state machine workflow will be added to the project. This template is often used for testing purposes.
|
|
Workflow Activity Library
|
Sets up a dynamic link library project and adds references to all the needed .NET Framework assemblies for WF. A new activity will be added to the project. This is used for building custom activities to augment the collection of out of the box activities that come with WF.
|
|
SharePoint 2007 Sequential Workflow
|
Sets up a sequential workflow for use inside of SharePoint 2007. All the needed references for both WF and SharePoint 2007 will be added to the project. You will receive an error if you try to create this type of project without SharePoint 2007 installed on your development machine.
|
|
SharePoint 2007 State Machine Workflow
|
Sets up a state machine workflow for use inside of SharePoint 2007. All the needed references for both WF and SharePoint 2007 will be added to the project. You will receive an error if you try to create this type of project without SharePoint 2007 installed on your development machine.
|
Figure 8 – Workflow Templates in Visual Studio 2008
We are going to use an Empty Workflow Project so that we can build it up manually and learn about all the workflow features of Visual Studio 2008. Once an Empty workflow project is selected as shown in Figure 7 and the OK button is clicked then a new empty workflow project is created. Figure 9 shows how Visual Studio 2008 will appear once an Empty Workflow Project has been created. The Empty Workflow Project template sets up a dynamic link library project with references to the Workflow Foundation assemblies. This can be verified by expanding the references node in the Project Explorer which is located on the right hand side of Figure 9. As can be seen from the project explorer shown in Figure 9 we have several references to assemblies that are part of the .NET Framework. The assemblies that are specific to Workflow Foundation are:
· System.Workflow.Activities
· System.Workflow.ComponentModel
· System.Workflow.Runtime
· System.WorkflowServices
The other assemblies that you see referenced in Figure 9 are common framework assemblies that come in handy when building all component types.
Figure 9 – Empty Workflow Project
Adding Workflow Items to a Workflow Project
The Project Explorer also allows access to all files which make up the project. This includes a project’s code files and its configuration file. However, since the Empty Workflow Project template does not add any files to a project we will have to manually add workflow files to this project. This can be done by using the Add Item Dialog. This dialog can be brought up by right clicking the project node of the Project Explorer and selecting Add and then selecting New Item… as shown in Figure 10. Notice in Figure 10 that there are a few workflow specific items that make it easy to quickly add Sequential Workflows, State Machine Workflows, and Activities to a project. We will use the New Item dialog so that we can see all the available options.
Figure 10 – Adding a new item to a workflow project
Figure 11 – Add Item Dialog
Figure 11 shows what the Add Item Dialog box looks like when invoked from a workflow project. Notice that we are only looking at workflow related items because the Workflow category is selected in the left hand side of Figure 11. As you can see there are many different types of workflows that can be added to a workflow project. This dialog displays all these options in alphabetical order. Figure 12 below lists all the workflow items along with a brief description of each item.
|
Item
|
Purpose
|
|
Activity
|
Creates a custom activity. Everything generated by the designer uses the project’s language (for example C# or VB.NET).
|
|
Activity (with code separation)
|
Creates a custom activity using a XAML file to represent what is specified by the WF activity designer.
|
|
Sequential Workflow (code)
|
Creates a sequential workflow. Everything generated by the designer uses the project’s language (for example C# or VB.NET).
|
|
Sequential Workflow (with code separation)
|
Creates a sequential workflow using a XAML file to represent what is specified in the WF sequential workflow designer.
|
|
State Machine Workflow (code)
|
Creates a state machine workflow. Everything generated by the designer uses the project’s language (for example C# or VB.NET).
|
|
State Machine Workflow (with code separation)
|
Creates a state machine workflow using a XAML file to represent what is specified in the WF state machine designer.
|
|
Web Configuration File
|
Creates a web.config file with a WorkflowRuntime section. This WorkflowRuntime section configures the workflow runtime such that it can be hosted by ASP.NET.
|
Figure 12 – Description of Workflow Items from the Add Item Designer
There are three different types of workflow artifacts that may be built with Workflow Foundation. They are Sequential workflows, State Machine workflows, and custom activities. Notice that there are two options for each type of artifact. For example, in Figure 12 you see two options for building a Sequential Workflow – they are Sequential Workflow (code) and Sequential Workflow (with code separation). Functionally these two options are identical. The difference between these two options pertains to the type of source code that the WF designers will generate. The “code separation” options produces XAML code to represent what is specified by a developer in one of the WF designers. XAML stands for Extensible Application Markup Language and is an XML dialect that is designer friendly. As a developer or architect you should never have to deal directly with XAML to build a WF workflow. It is the job of the WF designers to insulate you from this complexity.
The designers for Workflow Foundation that are integrated with Visual Studio allow these workflow artifacts to be built visually. In other words, there is a sequential workflow designer, a state machine designer, and a designer for building custom activities. The next section of this post will introduce these workflow artifacts and show the designers that Visual Studio provides for building each WF artifact. Future posts will investigate each one in more detail.
The WF Designers
The Sequential Workflow Designer, the State Machine Workflow Designer and the Activity Designer are shown in Figures 13, 14, and 15 respectively. All of these WF artifacts can be built up using the out of the box activities found in the WF toolbox. These artifacts can also be built up using custom activities. The WF toolbox is shown in Figure 16. Figure 16 shows all the activities that come with WF. The activities are listed in alphabetical order and are categorized according to the version of the .NET Framework in which they were delivered. Notice that the Receive and Send activities at the bottom of the figure are the only activities that were delivered with .NET 3.5. As mentioned earlier these activities allow for the integration of WF and WCF.
Sequential Workflows, like the one shown in Figure 13, are easy to comprehend because the activities you use to build them are similar to the commands that are built into modern programming languages. For example, IfElse, While, TransactionScope, and Parallel are all examples of out of the box activities that can be dropped directly onto a sequential workflow designer. Another important aspect about Sequential workflows is that they are deterministic. In other words they can figure out for themselves the course of action to take based on the information coming into them.
Figure 13 – A Sequential Workflow
State Machine Workflows, on the other hand, represent a different way of thinking about program flow. Figure 14 depicts a State Machine workflow. State machines are composed of state activities. With few exceptions the State activity is the only activity that can be dropped onto the State Machine designer. Think of a State Machine as a workflow that starts from an initial state and transitions from state to state until it reaches a completed state. Think of a state as a well known step, stage, or status within a business process. Possible State transitions are predefined by the developer. However, at runtime a state machine instance cannot determine when to transition - or - in cases where there is more than one allowable transition - the state machine cannot determine which transition to take. Outside intervention is required to determine when and where the workflow should transition. In other words, State Machines require an outside entity to tell them when to transition and which transition to take. Therefore, State Machine Workflows are non-deterministic.
Figure 14 – A State Machine Workflow
The final designer which is shown in Figure 15 allows custom activities to be built. As stated previously activities are the building blocks of all WF workflows. Out of the box WF provides all the activities shown in Figure 16. Custom activities allow development teams to extend these activities with activities that provide functionality that is unique to their business. For example, as development teams use WF to implement more and more business processes they may notice reoccurring workflow patterns. Or they may notice that there is existing logic trapped inside an existing .NET assembly that must be invoked from many different workflows. In both these situations a custom activity can be created and added to the WF toolbox to facilitate reuse.
Figure 15 – A Custom Activity
Figure 16 – The WF Toolbox showing all the out of the box activities
Summary
In this post I started with a brief history of Visual Studio and the .NET Framework. I then discussed the new multi-targeting capabilities of Visual Studio 2008. From there I showed how to create an empty Visual Studio solution, I then added an empty Workflow project to it. Finally I showed how to add Sequential Workflows, State Machine Workflows and Custom Activities to the workflow project. This allowed us to explore the project templates and workflow items for WF. I concluded with a brief description of Sequential workflows, State machine workflows, custom activities and their designers.
In my next post I’ll dive a little deeper into sequential workflows. I’ll build a simple sequential workflow with a few of the more common activities and then I’ll show how to run the workflow using the Workflow Runtime.
Tags:
7 comments so far...
Re: Using Visual Studio 2008 to Create Workflow Foundation Projects
it's very good but we need example source code also
By yashwanth kumar on
10/22/2008 12:37 AM
|
Re: Using Visual Studio 2008 to Create Workflow Foundation Projects
How can we start this Workflow
By NIkhil on
2/20/2009 1:51 AM
|
Re: Using Visual Studio 2008 to Create Workflow Foundation Projects
All of the workflows shown here are for illustration only. I did not build out the code behind files or a host. My subsequent posts on WF have running demos.
Sorry,
Keith
By keithpij on
2/23/2009 2:00 PM
|
Re: Using Visual Studio 2008 to Create WEB SERVICE
Can You help me to create a web service.that it can run in PC orther, you can send me to my mail (ngthtra@yahoo.com). Thank you very much!!!!
By MR TEA on
11/16/2009 10:55 PM
|
Re: Using Visual Studio 2008 to Create Workflow Foundation Projects
By <html> on
2/18/2010 3:06 AM
|
Re: Using Visual Studio 2008 to Create Workflow Foundation Projects
GLT10a02peng24
nice article, i got good information, thanks for posting..chanel handbags
By chanel handbags on
2/24/2010 1:37 AM
|
Re: Using Visual Studio 2008 to Create Workflow Foundation Projects
I am very pleased to find your site on the web as it represents a great value for me and my family. autism resources
By Pete on
3/9/2010 10:22 AM
|