Windows Workflow Foundation Components

The following sections outline the various pieces of the Windows Workflow Foundation framework. These high-level items represent the functionality that is provided out of the box.

Workflows

The most obvious piece of Windows Workflow Foundation is the workflow itself. This includes items such as workflow design functionality, the different types of workflows, the infrastructure available to run the workflows, and the workflow development tools.

Types of Workflows

Windows Workflow Foundation provides two workflow types: sequential and state-machine. Each of these has its own distinct traits and set of activities that you can execute within a workflow instance. Chapter 1 introduces these workflow types as ordered and event-driven workflows, respectively. Sequential and state-machine workflows are simply how these types are referenced in the domain of Windows Workflow Foundation.

Sequential Workflows

A sequential workflow is probably the most common type of workflow and the prime example of what most people think about related to this topic. This type of workflow describes a process that has a beginning point, performs any number of actions in a given order, and then arrives at an end state.

You can easily spot the sequential workflow in the designer; it has a green indicator icon at the top of the workflow and a red icon at the bottom (see Figure 3-2). This should tip you off that workflows run from top to bottom, meaning that activities farther up the design surface execute first.

Figure 3-2

In sequential workflows, you can use several logic control constructs from traditional development, such as if-then statements and while loops. The difference is that these constructs are defined visually and declaratively rather than programmatically, as with C# or other programming languages.

State-Machine Workflows

State-machine workflows differ from sequential workflows in that they jump around in their execution rather than move in an ordered manner. These jumps are triggered by events, and each jump is to a defined state. State-machine workflows start in a beginning state; move to and from any number of interim states; and then arrive in an end state, at which point the workflow instance is complete.

When to Use What

You might opt to use the sequential workflow by default because it is such a common way of thinking about the flow of processes. However, here are some instances where using the state-machine workflow type is the best option:

• When events external to the workflow dictate the next step

• When the order of work activities is not always the same or predictable

• When human interaction is prevalent throughout the process

• When you’re using a sequential workflow, and it becomes increasingly difficult to model all the possible execution paths (which may be a sign that you are using the wrong type of workflow)

Activities

Activities are the basic building blocks of workflows built on Windows Workflow Foundation. When a workflow instance is started, activities are executed as defined in the workflow definition until the last activity is executed, at which point the workflow is complete.

Activities are meant to be standalone pieces of functionality that can be reused multiple times within a workflow or across multiple workflows. Additionally, activities generally have some configurable properties.

Workflows Are Activities

Workflows themselves are actually implemented as activities. SequentialWorkflowActivity and StateMachineWorkflowActivity, the classes that represent the two workflow types introduced previously, both indirectly inherit from System.Workflow.ComponentModel.Activity. This means you can theoretically develop your own workflow types - however, you would probably not need to do this very often. In addition, because workflows are actually activities, they have the same behavior and properties as other activities.

The following code defines the Activity class. You can find this metadata by navigating to the Activity class definition in Visual Studio:

  public class Activity : DependencyObject {     public static readonly DependencyProperty ActivityContextGuidProperty;     public static readonly DependencyProperty CancelingEvent;     public static readonly DependencyProperty ClosedEvent;     public static readonly DependencyProperty CompensatingEvent;     public static readonly DependencyProperty ExecutingEvent;     public static readonly DependencyProperty FaultingEvent;     public static readonly DependencyProperty StatusChangedEvent;     public Activity();     public Activity(string name);     public string Description { get; set; }     public bool Enabled { get; set; }     public ActivityExecutionResult ExecutionResult { get; }     public ActivityExecutionStatus ExecutionStatus { get; }     public bool IsDynamicActivity { get; }     public string Name { get; set; }     public CompositeActivity Parent { get; }     public string QualifiedName { get; }     protected Guid WorkflowInstanceId { get; }     public event EventHandler<ActivityExecutionStatusChangedEventArgs> Canceling;     public event EventHandler<ActivityExecutionStatusChangedEventArgs> Closed;     public event EventHandler<ActivityExecutionStatusChangedEventArgs>         Compensating;     public event EventHandler<ActivityExecutionStatusChangedEventArgs> Executing;     public event EventHandler<ActivityExecutionStatusChangedEventArgs> Faulting;     public event EventHandler<ActivityExecutionStatusChangedEventArgs>         StatusChanged;     protected internal virtual ActivityExecutionStatus Cancel(         ActivityExecutionContext executionContext);     public Activity Clone();     protected internal virtual ActivityExecutionStatus Execute(         ActivityExecutionContext executionContext);     public Activity GetActivityByName(string activityQualifiedName);     public Activity GetActivityByName(string activityQualifiedName,         bool withinThisActivityOnly);     protected internal virtual ActivityExecutionStatus HandleFault(         ActivityExecutionContext executionContext, Exception exception);     protected internal virtual void Initialize(IServiceProvider provider);     public static Activity Load(Stream stream, Activity outerActivity);     public static Activity Load(Stream stream, Activity outerActivity,         IFormatter formatter);     protected internal virtual void OnActivityExecutionContextLoad(         IServiceProvider provider);     protected internal virtual void OnActivityExecutionContextUnload(         IServiceProvider provider);     protected virtual void OnClosed(IServiceProvider provider);     protected internal void RaiseEvent(DependencyProperty dependencyEvent,         object sender, EventArgs e);     public void RegisterForStatusChange(DependencyProperty dependencyProp,         IActivityEventListener<ActivityExecutionStatusChangedEventArgs>             activityStatusChangeListener);     public void Save(Stream stream);     public void Save(Stream stream, IFormatter formatter);     public override string ToString();     protected void TrackData(object userData);     protected void TrackData(string userDataKey, object userData);     protected internal virtual void Uninitialize(IServiceProvider provider);     public void UnregisterForStatusChange(DependencyProperty dependencyProp,         IActivityEventListener<ActivityExecutionStatusChangedEventArgs>             activityStatusChangeListener); } 

Base Activity Library

The Windows Workflow Foundation framework ships with more than 30 activities in the base activity library (BAL). The BAL contains activities from the most basic control logic to more complex activities, such as invoking remote web services. Figure 3-3 shows all the BAL activities within the Visual Studio Toolbox.

Figure 3-3

There are also some activities that are specific to the state-machine workflow type (see Table 3-1).

Table 3-1: State-Machine Activity Classes
Open table as spreadsheet

Class	Description
EventDrivenActivity	Allows a workflow state to be executed based on the firing of an event external to the workflow instance.
SetStateActivity	Allows the explicit transition to a new workflow state.
StateActivity	Symbolizes a workflow state.
StateInitializationActivity	This activity can contain child activities that execute when a workflow state is entered.
StateFinalizationActivity	This activity can contain child activities that execute when a workflow state is ending.

Custom Activities

Because Windows Workflow Foundation is extensible to its core, you can easily create new activities to meet specific business needs. Custom activities could be something as generic as a SQL table-row insert or something very specific, such as creating an order within an existing line of business (LOB) system.

Chapter 6 describes the BAL and developing custom activities in greater detail.

Hosting

Because Windows Workflow Foundation is not a standalone product, it needs a host application in which to run. A host can be any type of .NET software, such as a Windows Forms, ASP.NET, console, Windows Service, or web service application.

Even though the workflow is where most of the interesting business logic takes place, the host plays a vital role in the lifecycle of workflow execution. The host is where the workflow is kicked off and, generally, where user interaction takes place.

The Runtime Engine

The Windows Workflow Foundation runtime engine is what makes workflows go, essentially. What it isn’t, however, is a separate service or process. In fact, the workflow runtime engine runs in the same process as the host application.

The workflow runtime engine also exposes several events that let your application when a workflow instance is completed, aborted, or has gone idle. Another important piece of Windows Workflow Foundation is the concept of runtime services (discussed later in this chapter). The workflow runtime engine manages the addition, removal, and execution of these runtime services.

Communication with the Host

Workflows do not execute in a vacuum; hence, Windows Workflow Foundation provides facilities for back-and-forth communication between a workflow instance and its host. There are communication methods that enable you to quickly and easily pass data in and out of a workflow, and more customizable methods that can handle external events and call methods outside a workflow instance’s context. Parameters allow simplistic communication between a workflow instance and its host. When you start a workflow in a host application by calling the CreateWorkflow method of the WorkflowRuntime class, you can pass a Dictionary<string, object> instance that contains items of interest to a workflow. Conversely, you can obtain a Dictionary<string, object> instance in a WorkflowCompleted event handler. This instance can contain any number of variables from the workflow, which can then be used in the calling host application.

Another form of workflow communication is called local communication services. This type of communication is performed with classes through events and methods. The host can talk to the workflow by firing events, which are then handled internally by the workflow. The workflow can also communicate with the host by calling methods on the communication service class. This is an elegant form of communication because it uses concepts already familiar to developers.

Using local communication services is easy. First, you need to develop a .NET interface that defines the events and methods to be used for communicating back and forth between the host and a workflow instance. The following code shows an example interface:

  [ExternalDataExchangeAttribute] public interface ITalkWithMe {     void TellSomethingToTheHost(string message);     event EventHandler<EventArgs> NotifyTheWorkflow; } 

The next step is to create a class that implements this interface, as follows:

  public class TalkWithMeService : ITalkWithMe {     public void TellSomethingToTheHost(string message)     {         System.Windows.Forms.MessageBox("The workflow told me: " + message);     }     public event EventHandler<EventArgs> NotifyTheWorkflow;     public void SendAnEventToTheWorkflow()     {         NotifyTheWorkflow(this,             new ExternalDataEventArgs(WorkflowEnvironment.WorkflowInstanceId));     } } 

A couple of interesting things are going on with the interface and the TalkWithMeService class. First, notice that the ITalkWithMe interface has an ExternalDataExchange attribute. This tells Windows Workflow Foundation that this is a local communication service. Next, take a look at the TellSomethingToTheHost implementation in the TalkWithMeService class. This method is called from within the workflow instance and a string message is passed. The SendAnEventToTheWorkflow method is provided so the host can raise the NotifyTheWorkflow event. The workflow should have a handler already wired up so that it can handle this event.

Chapter 5 discusses the concept of workflow hosting, which includes communication between workflows and the host. Workflow communication discussed in the previous context does not include communication using web services. However, this type of communication is very important and is supported on the Windows Workflow Foundation platform. Chapter 14 discusses workflows and web services.

Runtime Services

The following sections discuss the concept of runtime services. Runtime services consist of out-of-the-box and custom classes that essentially live in the workflow runtime engine during execution. These runtime services perform specific tasks related to workflow execution and maintenance.

Out-of-the-Box Services

There are several types of runtime services included with the base workflow framework. These classes provide functionality that is generic to a problem domain and commonly needed in many scenarios. The following sections describe the different classifications of out-of-the-box services.

Transaction Services

Transaction runtime services, or commit batch services, enable you to maintain integrity in workflow applications. Transactions are generally defined as a group of activities (not necessarily workflow-type activities) that must occur successfully as a whole. If one of the activities in a chain fails, the actions that have already occurred are undone - this is called a rollback. However, transactions that run over long periods of time cannot always be undone; rather, some logic is implemented to maintain a stable workflow state. This is called compensation.

The classic example is an ATM transaction. If a customer is performing a monetary transfer between accounts and an error occurs, the software needs to ensure that one account was not debited without the other account’s being credited. From this simple example, you can see that transactions are extremely vital to software systems.

The transaction runtime service infrastructure included in Windows Workflow Foundation supports two types of transactions: ACID and long running.

ACID Transactions

ACID transactions refer to the types of transactions that are traditionally associated with a relational database. The driver behind transactions ensures that a system is left in a stable and valid state before and after an action or manipulation of data. The ACID acronym defines this particular classification of transactions, as follows:

• Atomic - This property states that either all or none of the activities included in the scope of the transaction are completed.

• Consistent - This means that a workflow must be in a valid state before and after a transaction is executed.

• Isolated - If a transaction is isolated, no entity outside the transaction can see what the workflow’s state looks like before the transaction is committed or rolled back.

• Durable - This means that after a transaction is successfully implemented, its outcome is not lost.

Long-Running Transactions

Given the ACID properties, transactions that last over long periods of time do not meet the descriptions of every category. The only properties that long-running transactions meet are consistency and durability. They are not atomic because certain activities in this type of transaction cannot be undone. For example, if an e-mail is sent to a customer regarding a recent order and then the order fails for some reason, the e-mail cannot be unsent. Rather, the transaction should contain compensation logic that can attempt to smooth out any actions that previously occurred. The customer whose order failed could be sent a second e-mail informing him or her of the error, for example.

Long-running transactions are also not isolated. This makes sense because there might be a long period of time between steps, and a software system cannot hide the changes while waiting to continue, the way a database can during a transaction that lasts a matter of seconds.

Persistence Services

Think back to Chapter 1, where the four workflow tenets were introduced. One of these tenets stated that workflows needed to be long-running and stateful. This tenet is important because workflows that interact with external entities such as humans and exterior services should be able to sleep while outside parties are performing work.

Because it doesn’t make sense for a workflow’s state to be permanently stored in volatile memory, Windows Workflow Foundation provides an architecture conducive to persisting active workflows to a durable medium. Probably the most common scenario, and one that is supported natively, is persisting state to a relational database such as SQL Server.

The SqlWorkflowPersistenceService class, provided out of the box, provides developers with an easy and transparent way to maintain workflow state over long periods of time. When a workflow instance becomes idle while waiting for some kind of outside input, the runtime engine recognizes this, and any active persistence service writes the workflow’s state to its respective data store.

Tracking Services

Tracking services enable you to monitor and record the execution of workflows. If you remember the workflow tenets introduced in Chapter 1, tracking covers allowing workflows to be transparent throughout their lifecycle.

Tracking services use the concepts of tracking profiles and tracking channels to specify which activities are reported and to what kind of medium. The TrackingProfile and TrackingChannel classes are used to represent these concepts, respectively. The abstract TrackingService class is responsible for managing these profiles and channels for the workflow runtime.

Out of the box, Windows Workflow Foundation provides the SqlTrackingService class, which allows you to persist workflow execution data to a SQL Server database. In addition to tracking data, you can store and maintain tracking profiles in the database.

Aside from defining tracking profiles in the aforementioned TrackingProfile class, you can define profiles in XML. The following code shows an example of what an XML-defined tracking profile might look like:

  <?xml version="1.0" encoding="utf-16" standalone="yes"?> <TrackingProfile     xmlns="http://www.microsoft.com/WFTrackingProfile" version="3.0.0">     <TrackPoints>         <WorkflowTrackPoint>             <MatchingLocation>                 <WorkflowTrackingLocation>                     <TrackingWorkflowEvents>                         <TrackingWorkflowEvent>Created</TrackingWorkflowEvent>                         <TrackingWorkflowEvent>Completed</TrackingWorkflowEvent>                     </TrackingWorkflowEvents>                 </WorkflowTrackingLocation>             </MatchingLocation>         </WorkflowTrackPoint>         <ActivityTrackPoint>             <MatchingLocations>                 <ActivityTrackingLocation>                     <Activity>                         <Type>System.Workflow.ComponentModel.Activity,                               System.Workflow.ComponentModel, Version=3.0.0.0,                               Culture=neutral, PublicKeyToken=31bf3856ad364e35                         </Type>                         <MatchDerivedTypes>true</MatchDerivedTypes>                     </Activity>                     <ExecutionStatusEvents>                         <ExecutionStatus>Executing</ExecutionStatus>                         <ExecutionStatus>Faulting</ExecutionStatus>                     </ExecutionStatusEvents>                 </ActivityTrackingLocation>             </MatchingLocations>         </ActivityTrackPoint>     </TrackPoints> </TrackingProfile> 

This XML tells the workflow runtime tracking service a couple of things. First, it declares that there are two workflow-level events that should be tracked: the Created and Completed events.

Additionally, the nodes in the ActivityTrackingLocation element define which events of the base Activity class are noteworthy. Every time the Executing and Faulting events are fired, a call is made to record this information. Because the Type node points to the System.Workflow.ComponentModel.Activity class and all workflow activities derive from this class, these events are tracked for every type of activity.

Scheduling Services

Scheduling services enable you to define how workflows are executed related to threading. By default, Windows Workflow Foundation runs workflows in an asynchronous manner. This means that when a workflow is started from within a host application, the workflow spawns on a separate thread, and control is immediately returned to the host. This is a nice way to do things if you are developing in a Windows Forms application because the end user should be able to manipulate the user interface (UI) while workflows are running in the background. It wouldn’t make much sense to lock the application’s UI for a long period of time while the user is waiting for the workflow to finish.

However, in application scenarios such as in ASP.NET web forms or web services, which execute on the server, it might make sense to lock the thread until the workflow returns control. Both of the scenarios mentioned are provided natively with Windows Workflow Foundation.

Custom Services

The previous sections related to workflow runtime services discuss the out-of-the-box functionality included with Windows Workflow Foundation. Although these classes provide a rich set of services, often specific needs arise that call for the development of custom runtime services.

For example, a workflow development effort might require that workflow tracking data be sent to a web service upon failure of a workflow instance. This is relatively easy to implement given the base framework provided with Windows Workflow Foundation.

You can extend every type of runtime service and develop new types of runtime services. Chapter 7 discusses out-of-the-box runtime services in more detail and explains how to develop custom services.

Rules

Business processes and business rules go hand in hand. Business rules are the entities that define how software makes workflow decisions. One distinction between business rules and business processes is how often each of them changes.

Business processes are assumed to be well tested and defined; therefore, you do not need to modify their workflow on a regular basis. Conversely, business rules can change all the time. For example, a set of pricing rules for an e-commerce website might dictate how promotions are handled. The user might receive free shipping on his or her order if the order total is more than $50, and this threshold could change weekly or monthly. The important thing is that business rules should be flexible and easy to modify.

Windows Workflow Foundation provides a rich infrastructure for designing and executing rules. However, to define simple decision-making logic, you can use traditional code. For example, the IfElse activity, which is introduced in the Hello World example in Chapter 2, determines the branch to execute based on code written in C#.

However, for serious process implementation that depends on a great deal of business logic, you should consider the business-rules framework. In general, these rules are related sets. One rule set might contain rules related to human resources and recruiting, whereas another set might define rules for inventory management.

You can think of rules as if-then-else statements. The if portion of a rule generally inspects some property or properties of the current execution process, such as an order amount or a user’s security roles. The then actions define what occurs when the Boolean output of the if condition evaluates to true. The else actions occur when the if statement evaluates to false. Although these concepts are fairly elementary and familiar to anyone who has developed software, Windows Workflow Foundation enables you to define these rules in an encapsulated and flexible manner.

Windows Workflow Foundation provides the Rule Set Editor (see Figure 3-4) for defining rules within Visual Studio. You can access this screen with the RuleSetReference property of a Policy activity in the workflow designer.

Figure 3-4

You can see here that the FreeShipping rule is inspecting a variable called orderAmount for a value greater than or equal to $50. If this turns out to be the case during runtime, the shippingCost variable is set to $0. In this example, an else action has not been provided.

Rule definitions are stored in a separate XML file that is external to the executable code. This allows for easy modification, even during workflow execution. The following is a snippet from the rules XML file for the FreeShipping rule:

  ... <Rule Name="FreeShipping" ReevaluationBehavior="Always" Priority="0"  Description="{p3:Null}" Active="True">   <Rule.ThenActions>     <RuleStatementAction>       <RuleStatementAction.CodeDomStatement>         <ns0:CodeAssignStatement LinePragma="{p3:Null}"          xmlns:ns0="clr-namespace:System.CodeDom;Assembly=System, Version=2.0.0.0,          Culture=neutral, PublicKeyToken=b77a5c561934e089">           <ns0:CodeAssignStatement.Left>             <ns0:CodeFieldReferenceExpression FieldName="shippingCost">               <ns0:CodeFieldReferenceExpression.TargetObject>                 <ns0:CodeThisReferenceExpression />               </ns0:CodeFieldReferenceExpression.TargetObject>             </ns0:CodeFieldReferenceExpression>           </ns0:CodeAssignStatement.Left>           <ns0:CodeAssignStatement.Right>             <ns0:CodePrimitiveExpression>               <ns0:CodePrimitiveExpression.Value>                 <ns1:Int32 xmlns:ns1="clr-namespace:System;Assembly=mscorlib,                  Version=2.0.0.0, Culture=neutral,                  PublicKeyToken=b77a5c561934e089">0</ns1:Int32>               </ns0:CodePrimitiveExpression.Value>             </ns0:CodePrimitiveExpression>           </ns0:CodeAssignStatement.Right>         </ns0:CodeAssignStatement>       </RuleStatementAction.CodeDomStatement>     </RuleStatementAction>   </Rule.ThenActions>   <Rule.Condition>     <RuleExpressionCondition Name="{p3:Null}">       <RuleExpressionCondition.Expression>         <ns0:CodeBinaryOperatorExpression Operator="GreaterThanOrEqual"          xmlns:ns0="clr-namespace:System.CodeDom;Assembly=System, Version=2.0.0.0,          Culture=neutral, PublicKeyToken=b77a5c561934e089">           <ns0:CodeBinaryOperatorExpression.Left>             <ns0:CodeFieldReferenceExpression FieldName="orderAmount">               <ns0:CodeFieldReferenceExpression.TargetObject>                 <ns0:CodeThisReferenceExpression />               </ns0:CodeFieldReferenceExpression.TargetObject>             </ns0:CodeFieldReferenceExpression>           </ns0:CodeBinaryOperatorExpression.Left>           <ns0:CodeBinaryOperatorExpression.Right>             <ns0:CodePrimitiveExpression>               <ns0:CodePrimitiveExpression.Value>                 <ns1:Int32 xmlns:ns1="clr-namespace:System;Assembly=mscorlib,                  Version=2.0.0.0, Culture=neutral,                  PublicKeyToken=b77a5c561934e089">50</ns1:Int32>               </ns0:CodePrimitiveExpression.Value>             </ns0:CodePrimitiveExpression>           </ns0:CodeBinaryOperatorExpression.Right>         </ns0:CodeBinaryOperatorExpression>       </RuleExpressionCondition.Expression>     </RuleExpressionCondition>   </Rule.Condition> </Rule> ... 

Although you don’t have to understand completely what is going on in the preceding XML, you can see that the rule is defined in a declarative manner and that the markup should be consumable by anything that understands the rule-set schema.

There is a lot more to the rules infrastructure, such as rules-related activities and chaining. Chapter 9 covers the entire gamut of rules-related topics.

Visual Studio

Visual Studio is the key tool for developing workflows. Microsoft has made great strides to provide a consistent and familiar development environment across technologies, including ASP.NET, Windows Forms, SQL Server, and BizTalk, to name a few. If you have used Visual Studio to develop software in the past, you should be able to find your bearings rather quickly when learning the Windows Workflow Foundation development paradigm.

Familiar components and concepts, such as project templates, the Toolbox, the Solution Explorer, debugging, and the like, are all part of the development experience in Visual Studio. Figure 3-5 shows a Visual Studio 2005 development screen with some of these items displayed.

Figure 3-5

Visual Studio also supports the development of .NET code, which is important if you are going to use Windows Workflow Foundation to create custom components. In addition, the workflow components for Visual Studio provide several different authoring models, including the declarative XAML and the code-only style.

The Visual Studio environment for Windows Workflow Foundation is covered in detail in Chapter 4.

Windows Workflow Utilities

Just like the .NET software development kit (SDK), the Windows Workflow Foundation SDK ships with command-line utilities to assist with development.

wca.exe

Workflow-to-host communication has already been mentioned as a vital component of the Windows Workflow Foundation architecture. One of the ways a workflow can communicate with its host is through a data-exchange service. This is a class that implements a .NET interface with the ExternalDataExchange attribute.

The wca.exe command-line utility generates a set of strictly bound classes that are derived from already-written data exchange classes. Without these strictly bound classes, the Windows Workflow Foundation runtime engine uses reflection to manipulate the data exchange classes. Therefore, there is a slight performance advantage when you use the generated code. In addition, the generated classes provide designable components, which means that icons appear in the Toolbox for external methods and event handlers. This offers an improved development experience.

Because this utility is related to workflow communication, it is covered in greater detail in Chapter 5.

wfc.exe

The wfc.exe utility is the Windows Workflow Foundation command-line compiler. It enables you to compile workflows and activities outside the Visual Studio environment (as discussed in detail in Chapter 4). Table 3-2 lists the wcf.exe options.

Table 3-2: wcf.exe Options
Open table as spreadsheet

Command-Line Option	Short Form	Description
/out:<file>		Outputs a file name.
/target:assembly	/t:assembly	Builds a Windows Workflow Foundation assembly (default).
/target:exe	/t:exe	Builds a Windows Workflow Foundation application.
/target:codegen	/t:codegen	Generates a partial class definition.
/delaysign[+|-]		Delays the signing of the assembly using only the public portion of the strong name key.
/keyfile:<file>		Specifies a strong name key file.
/keycontainer:<string>		Specifies a strong name key container.
<XAML file list>		Specifies XAML source file names.
<vb/cs file list>		Specifies code-beside file names.
/reference:<file list>	/r:	References metadata from the specified assembly files.
/library:<path list>	/lib:	Specifies a set of directories that contain references.
/debug[+|-]	/d:	Emits full debugging information. The default is +.
/nocode[+|-]	/nc:	Disallows code-beside and code-within models. The default is -.
/checktypes[+|-]	/ct:	Checks for permitted types in the wfc.exe.config file. The default is -.
/language:[cs|vb]	/l:	Specifies the language to use for the generated class. The default is cs (C#).
/rootnamespace:<string>	/rns:	Specifies the root namespace for all type declarations. Valid only for the VB (Visual Basic) language.
/help	/?	Displays this usage message.
/nologo	/n	Suppresses compiler copyright message.
/nowarn	/w	Ignores compiler warnings.