Comparing SharePoint Designer 2007 and Visual Studio 2005 Designer

SharePoint Designer 2007 workflows are also referred to as no-code workflows. All activities used within a SharePoint Designer 2007 workflow are well-known safely registered libraries that already have been deployed on the server.

Note 

A safely registered library is a .NET assembly that is registered as an entry on the SharePoint virtual server Web.config <SafeControls> list. Detailed information about this topic can be found in Chapter 31, "Administrating Code Access Security."

SharePoint Designer 2007 does not allow you to create your own activities, although it is able to generate raw XOML data, which is stored on the SharePoint server. During workflow execution time, the XOML data is interpreted by the runtime engine, which ensures that all activities used within a workflow are marked as safe. It is possible to use custom activities that are created using Visual Studio 2005, as opposed to using one of the predefined activities. Such activities have to be marked on the SharePoint virtual server as being safe.

What Is the Same

Visual Studio 2005 Designer and SharePoint Designer 2007 both offer the following capabilities:

• You can create workflows for SharePoint Designer 2007.

• A workflow markup file is generated. If you are using SharePoint Designer, a workflow markup file is generated after selecting and configuring the conditions and actions for a workflow. The workflow markup file is generated as soon as you click the Finish button of the Workflow Designer Wizard. Visual Studio 2005 Designer has a graphical tool that helps to create the workflow markup file. Visual Studio 2005 Designer lets you create a graphical model representing the workflow, and the workflow markup file is generated based on this representation.

• Workflows can be started based on certain events, such as the creation of a new document, and they can also be started manually. You can define multiple initiation forms that gather information from users. Initiation forms are displayed when users manually start a workflow on a SharePoint item.

• You can use custom forms for users to interact with SharePoint tasks.

The following three types of forms are used in SharePoint Designer 2007 workflows:

• Association and initiation forms are displayed to users and need to be filled out before the workflow itself is started.

• Modification forms present options to users that change the course of the workflow itself as it is running on an item. For example, a user might redirect the task of a document review to another person.

• Task forms are custom forms that help to create tasks that are the result of the workflow process, and they can be used to specify detailed information about a task. For example, if a user finishes a document review, this might lead to the creation of a new task. As a result, the original author needs to review the document. The reviewer might use the task form to write some additional comments directed to the author.

Note 

Windows SharePoint Services 3.0 workflows are forms agnostic. This means that you can use any forms technology you want, as long as the forms created are capable of invoking the Windows SharePoint Services object model, generating the data necessary to send to the Windows SharePoint Services object model, and receiving and parsing the required data from the Windows SharePoint Services object model. Currently, you can build workflow forms using ASP.NET or InfoPath.

What Is Different

The ways in which workflows authored in SharePoint Designer 2007 differ from those created using the Visual Studio 2005 Designer for Windows Workflow Foundation is described in the "Windows Workflow Authoring" section earlier in this chapter. Table 28-1 provides an overview of the differences between Visual Studio 2005 Designer for Windows Workflow Foundation and SharePoint Designer 2007 when it comes to creating workflows.

Table 28-1: Workflow Development Tools Differences
Open table as spreadsheet

Visual Studio 2005 Designer for Windows Workflow Foundation	Office SharePoint Designer 2007
Code-behind files enable developers to write custom C# or Visual Basic code to express business logic.	No code-behind files; workflow rules files declaratively encapsulate business logic instead.
Workflow is authored as a template, which can be associated with multiple sites and lists.	Workflow is authored against a specific list and is data-bound to it at design time.
Workflow markup files, or markup and code-behind files, are compiled into a workflow assembly.	Workflow markup, workflow rules, and supporting files are not compiled into an assembly and are stored directly in a specific document library on a SharePoint site.
Workflow template must be associated with each list on which it is to be available.	Association happens when the workflow is authored against the specific list; no later association is necessary or possible.
You can use any forms technology. For Microsoft technology, this currently comes down to the ability to include ASP.NET and InfoPath forms in SharePoint workflows.	ASP.NET forms are automatically generated, and you can then customize them.
You can include workflow modifications.	Workflow modifications are not available. Workflow modifications are options that you present to your users to change the course of the workflow as it is running on an item. For example, you can allow a user to assign her tasks to another user.
You can author custom activities for inclusion in workflows.	You must use activities that are already provided on the SharePoint server.
Workflow assembly and workflow definition are packaged as a SharePoint Feature and deployed to a SharePoint site.	Deployment to a specific list or library happens automatically.
Microsoft Visual Studio debugging is available.	No step-by-step debugging is available.
You can author both sequential and state workflows.	You can author only sequential workflows.

Considerations

If you need to decide whether to create a workflow using SharePoint Designer or Visual Studio 2005 Designer, keep the following points in mind. If you are using Visual Studio 2005 Designer, you can create workflow templates and custom workflow activities, and you can also include code in your workflow and design forms. Also, when you use Visual Studio 2005 Designer, you are not programming a workflow against a specific SharePoint site. At a later time, you will be able to associate the newly created workflow with multiple SharePoint sites.

If you use SharePoint Designer 2007 to create a workflow, you are always designing a workflow for a specific SharePoint site. SharePoint Designer 2007 enables you to create declarative, rule-based workflows, and it lets you use pre-existing activities that are already deployed on the SharePoint server in your workflows. You cannot create your own activities or write code-behind pages. However, you can create new activities in Visual Studio 2005 Designer and use these to extend the set of activities located on the SharePoint server. After doing so, you can use those extended activities in SharePoint Designer 2007 workflows.

Code-Behind and Code-Beside Files

In the discussion about creating workflow applications so far, code-behind files have been mentioned now and then. As an administrator, you probably won't have to deal with this concept on a daily basis, but it might be useful to take a moment to elaborate on this topic.

Code-behind files are a concept best known from the ASP.NET world, where every .aspx page is compiled on request and ultimately inherits from a base class called Page. Code-behind files help to separate user interface code from page controller logic by forming an intermediate class that sits between the .aspx page and the ultimate Page base class. Code-behind files are usually compiled into assemblies and placed in the /bin directory of an ASP.NET application. Because the .NET common language runtime (CLR) automatically adds references to assemblies placed in the /bin directory, the .aspx page will have no trouble finding the code-behind class.

With the advent of ASP.NET 2.0, the code-behind model has changed to a code-beside model. Using the new concept of partial classes that allow one class to be defined in multiple source files, the .aspx file does not have to inherit from the code-behind file anymore. Instead, the .aspx file and the code-behind file are both partial classes that form a single class after compilation. The result of this is cleaner code.

Whenever this chapter refers to code-behind files, we are referring to partial classes that will be merged with other source files during compilation.