mattonsoftware.com

PPUtil: A Utility for Publisher Policy Generation

2007-03-11T09:23:00Z

The conventional method of creating publisher policy (PP) assemblies becomes cumbersome when dealing with many assemblies, and many earlier versions of assemblies¹.

PPUtil is a configuration-based utility for generating PP for many assemblies/versions. This tool was authored using .NET 2.0, however, the resultant PP assemblies can be used with .NET 1.0/1.1-compiled assemblies.

Download

Binaries: PPUtil_Binaries_v1_0_0_0.zip
Source: PPUtil_Source_v1_0_0_0.zip

This work is licensed under a Creative Commons Attribution 3.0 License.

Usage

PPUtil configurationFile outputDirectory

Common Usage Scenarios

Redirect a specific earlier version of an assembly to a later version;
Redirect a range of earlier versions of an assembly to a later version.

In both scenarios, resolution of the redirection for the earlier assembly versions is limited to major/minor version combinations i.e. build and revision numbers are not considered. This is due to the design of the publisher policy mechanism itself.

Configuration Examples

Redirect a specific earlier version of an assembly to a later version

Use the oldVersion attribute of the bindingRedirect element to specify the specific earlier version to redirect from. The major/minor component of the oldVersion will typically correspond to the oldMajorMinorVersion attribute of the publisherPolicy element.

<publisherPolicy>
    <assemblies>
      <assembly name="SampleAssembly"
              publicKeyToken="baa3201a127d8068"
                strongNameKeyPath="SampleKey.snk" >
        <publisherPolicies>
          <publisherPolicy oldMajorMinorVersion="1.0" version="1.0.0.0">
            <bindingRedirect oldVersion="1.0.0.0" newVersion="1.1.0.0" />
          </publisherPolicy>
        </publisherPolicies>
      </assembly>
    </assemblies>
</publisherPolicy>

Redirect a range of earlier versions of an assembly to a later version

Use the oldLowestVersion and oldHighestVersion attributes of the bindingRedirect element to specify the range of earlier versions to redirect from.

Tips

The provided configuration file must include a configuration section declaration for the publisherPolicy configuration section, as follows. The utility will also detect the absence of this declaration and prompt the user accordingly.

<configuration>
<configSections>
<section name="publisherPolicy" type="PublisherPolicyTool.Configuration.PublisherPolicyConfigurationSection, PPUtil" />
</configSections>
...
</configuration>

The PP assembly itself is versioned. When there are multiple versions of a PP assembly available, the version with the highest number is used. In .NET 1.0/1.1 a bug exists in the assembly loader whereby when determining the PP assembly with the highest number, the version numbers are sorted in alphabetic order, rather than numeric order.
The same strong name key used to sign the assembly the PP applies to must be used to sign the PP assembly;
When GACing a PP assembly, the generated PP configuration file must reside in the same folder as the PP assembly;
To diagnose binding issues, the binding resolution can be traced using fuslogw or output to disk by modifying registry values;

Acknowledgments

The idea of using the managed assembly builder APIs for PP generation was derived from Omers publisher policy generation sample.

Footnotes

1: Generating PP involves specifying the old version (major and minor version number resolution) of an assembly that the binding policy within the PP assembly will be applied to. The old version corresponds to an earlier version of an assembly that is referenced by dependent assemblies.

IIS 6: Logging Application Pool Recycling Events to the Event Log

2006-10-18T12:40:00Z

By default, IIS 6 logs application pool recycling events to the event log when memory limits are exceeded (noting that a memory limit is not set by default) and after elapsed time (29 hours by default).

There are other reasons for application pool recycling events, such as modifications to configuration files and manual recycling requests issued by administrators. Logging of recycling events to the event log is controlled by the LogEventOnRecycle metabase property (interpreted as a bitflag).

Updating the LogEventOnRecycle property to consider other recycling events can be achieved using adsutils.vbs, or by manually editing the metabase. The following examples enable logging for all possible recycling events.

Updating using adsutils.vbs

cscript adsutil.vbs Set w3svc/AppPools/DefaultAppPool/LogEventOnRecycle 255

Updating by Editing the Metabase

Stop IIS: iisreset -stop
Backup the metabase (found at: %WINDIR%\system32\inetsrv\MetaBase.xml)
Modify the LogEventOnRecycle property:

Branch :            /LM/W3SVC/AppPools/
Key Name:       LogEventOnRecycle
New Value:      255 (default is 137)

The metabase can be edited using the Metabase Explorer (available as part of the IIS 6 Resource Kit Tools).

Start IIS: iisreset -start

For further information about the LogEventOnRecycle metabase property, see the following articles:

How to modify Application Pool Recycling events in IIS 6.0
LogEventOnRecycle Metabase Property

Also note that IIS creates worker processes for application pools on demand. Thus, a recycle request may be issued but not result in an event log entry if no actual worker process is active. For more information:

Why IIS6 Application Pool Recycle Events are Not Logged

LibCheck: Highlight Public API Differences Between Assembly Revisions

2006-09-28T13:50:00Z

LibCheck is an assembly comparison tool that:

"... allows you to compare two versions of an assembly, and determine the differences. The tool reports the differences as a combination of 'removed' and 'added' APIs."

The comparison results present:

"removed" items: the original member has been either removed or modified;
"added" items: member has been added to the new version, or is a modified form of an original member;
breaking changes highlighted in red.

The following example compares two versions of an assembly.

Generating Metadata for Comparison

libcheck.exe -store AssemblyName FolderNameToStoreResults -full FolderContainingAssembly

For example:

libcheck.exe -store HelloWorld.dll 1.0.0.0 -full C:\HelloWorldV1\

libcheck.exe -store HelloWorld.dll 2.0.0.0 -full C:\HelloWorldV2\

Performing the Comparison

libcheck.exe -compare FolderContainingFirstStoreResults FolderContainingSecondStoreResults

For example:

libcheck.exe -compare 1.0.0.0 2.0.0.0

Here is an example comparison report.

Debugging Production Applications using ADPlus

2006-09-22T03:02:00Z

ADPlus is used to take snapshots of processes in environments where development-time debugging tools are not available e.g. Production server farms, end-users workstations. ADPlus is a Visual Basic script provided as part of the Debugging Tools for Windows that wraps the CDB debugger.

Snapshots of processes taken with ADPlus are analysed using the Windows Debugger (WinDbg). Managed processes in particular are analysed using SOS.dll, which contains extensions to WinDbg for debugging managed processes.

Practical applications include taking snapshots of WinForms and ASP.NET processes to interrogate unhandled exceptions, memory utilisation, resource contention etc.

Installing Debugging Tools for Windows in Target Environment

Download debugging tools;
XCOPY deploy to target environment;
Create a folder to store snapshots;
Set CScript as the default scripting engine (required by ADPlus, also requires Windows Script Host 5.6 or higher, interrogate version using CSCRIPT /? command)

CSCRIPT /H:CScript

Taking a Snapshop using ADPlus

The following examples demonstrate taking a snapshot of a WinForms process:

Via process id
ADPlus.vbs -c ADPlus_Config.xml -p 968
Via process name
ADPlus.vbs -c ADPlus_Config.xml -pn HelloWorldGUI.exe

Note that ADPlus will warn that the _NT_SYMBOL_PATH environment variable is not set. This is ok as the environment variable is not required for taking snapshots, however, it is required for analysing the snapshot later.

The following example ADPlus_Config.xml file configures ADPlus for Hang mode (hang mode instructs ADPlus to take the snapshot immediately, crash mode is another option that attaches the debugger to the process, then waits for process to exit before generating the snapshot):

<ADPlus>
    <Settings>
        <RunMode>HANG</RunMode>
        <Option>Quiet</Option>
      <OutputDir> C:\Snapshots </OutputDir>
    </Settings>
    
    <PreCommands>
        <Cmd> .load C:\Program Files\Debugging Tools for Windows\clr10\sos.dll </Cmd>
    </PreCommands>
    <Exceptions>
        
        
        <Config>
            <Code>
                 AllExceptions
            </Code>
            <Actions1>
                 FullDump;
            </Actions1>
            <ReturnAction1>
                 GN
            </ReturnAction1>
        </Config>
    </Exceptions>
</ADPlus>

Using WinDBG and SOS.dll

Install debugging tools;
Add installation location to PATH environment variable;
Create a folder to store symbols;
Add new environment variable, referencing the symbols folder:

Name: _NT_SYMBOL_PATH
Value: SRV*c:\temp\symbols* http://msdl.microsoft.com/download/symbols

This setting is used by WinDbg to dynamically download symbols (pdb files) on demand.

Launch WinDbg.exe;
Open the snapshot using File --> Open Crash Dump;
Load SOS.dll by entering the following command:

.load C:\Program Files\Debugging Tools for Windows\clr10\sos.dll

Useful WinDbg/SOS.dll commands are:

!help (all available commands)
!help <functionname> (help on provided function)
!clrstack (shows managed stack)
!dae (dumps all managed exceptions, noting that instances of ExecutionEngineException, StackOverflowException and OutOfMemoryException are normal)
!EEStack (shows full stack trace, including managed and unmanaged calls)
!do (dump object, including fields)

Further Information

How to use ADPlus to troubleshoot "hangs" and "crashes"

Production Debugging for .NET Framework Applications

Mini Dump Snapshots and the New SOS

Tips on Debugging Managed Exceptions with ADPlus and WinDbg

OPML Listing

2006-08-05T06:02:00Z

From time to time, I'm asked by my colleagues which feeds I subscribe to. The following is an OPML listing of my subscriptions:

IT Subscriptions.xml

Enjoy!

.NET Resources: Updated

2006-05-06T09:25:00Z

Managing hyperlinks via CommunityServer has become too cumbersome, I've shifted these resources to del.icio.us, as follows:

http://del.icio.us/MattDunn

You can also subscribe to changes via the following feed:

http://del.icio.us/rss/MattDunn

Many thanks to Grant for the tip!

Issues Migrating from .NET 1.0 to .NET 1.1

2006-03-06T11:48:00Z

Mainstream support for .NET 1.0 ends 30 June 2007. For organisations migrating from .NET 1.0 to .NET 1.1, the following changes are for consideration:

In addition to the changes listed above, the following issues were encountered during a recent migration activity.

Web Service WSDL Generation Issue

After upgrading websites from ASP.NET 1.0 to 1.1, the following error message may be encountered:

The XML element named 'HelloWorldMethodResponse' from namespace 'http://www.test.com' references a method and a type. Change the method's message name using WebMethodAttribute or change the type's root element using the XmlRootAttribute.

This error occurs when the WSDL for a web service is being generated. Note that the error message includes two possible solutions. The first of these solutions which recommends changing the web methods message name using the WebMethodAttribute is undesirable as this will alter the WSDL contract and break existing consumers. The second of the two solutions, applying the XmlRoot attribute to the web methods return type, will resolve the error, however, this requires recompilation of existing web service assemblies.

Properties of web methods that cause this error include:

The return type is a class or structure;
The return type is named [WebMethodName]Response;
The web method accepts no parameters (or has parameters that do not serialise to a complex type in the WSDL, for example, strings, integers).

This error does not affect the invocation of existing client proxies as they do not consume the WSDL at runtime. This issue will affect development activities when the WSDL is requested, for example, when re-generating client-side proxies using the Visual Studio Add/Update Web Reference feature.

To resolve this issue, apply the XmlRoot attribute to the return type of the WebMethod, noting the following:

The ElementName should be of the form [ResponseType]Dummy. Note that no element named HelloWorldMethodResponseDummy will appear in the WSDL;
The DataType property should be set to the response type.

An example application of the XmlRoot attribute is as follows:

[WebMethod(Description = "Test Method")]
[return: XmlRoot(Namespace = "http://www.test.com/",
        ElementName = "HelloWorldMethodResponseDummy",
        DataType = "HelloWorldMethodResponse",
        IsNullable = false)]
public HelloWorldMethodResponse HelloWorldMethod()
{
    return new HelloWorldMethodResponse();
}

Activator.CreateInstance() raises a System.MissingMethodException exception when creating instances of Arrays

In order for the Activator.CreateInstance() method to create instances of a given type, the type must define a public default constructor. In .NET 1.0, the Activator does not raise an exception when creating instances of Arrays (which has a private default constructor), however, this issue has been fixed for .NET 1.1 and now raises a System.MissingMethodException ("No parameterless constructor defined for this object") exception as expected.

To resolve this issue, the Array.CreateInstance() method can be used instead of Activator.CreateInstance(), as follows:

...

if (typeToInstantiate.IsArray)
{
    Type elementType = typeToInstantiate.GetElementType();
    newInstance = Array.CreateInstance(elementType, arraySize);
}
else
{
    newInstance = Activator.CreateInstance(typeToInstantiate);
}

Diagnosing Binary Formatter Version Incompatability Problems

2006-02-28T11:37:00Z

Clients consuming remoting services hosted in IIS (and therefore exposed via the HTTP channel) configured to use the binary formatter may receive the following error:

An unhandled exception of type 'System.Runtime.Serialization. SerializationException' occurred in mscorlib.dll

Additional information: BinaryFormatter Version incompatibility. Expected Version 1.0. Received Version 1008738336.1684104552.

This article explains that the above error is masking the original exception, and describes a mechanism for tracing this exception. However, this tracing process requires opening additional ports on the server, which may be problematic if the application under inspection is hosted in a secured environment.

An alternative to tracing the error is to configure the remoting service to use the SOAP formatter instead of the binary formatter, which will allow the original exception to propogate to the client correctly. The SOAP formatter is the default formatter for the HTTP channel, so assuming the remoting system is configured declaratively, the following elements can be removed/commented out of the configuration files:

Client

<configuration>
    <system.runtime.remoting>
        <application>
            <channels>
                <channel ref="http">
                    <clientProviders >
                        <formatter ref ="binary" />
                    </clientProviders >
                </channel>
            </channels>
        </application>
    </system.runtime.remoting>
</configuration>

Server

<configuration>
<system.runtime.remoting>
    <application>
      <channels>
        <channel ref="http"port="1234">
          <serverProviders >
            <formatter ref ="binary" />
          </serverProviders >
        </channel>
      </channels>
    </application>
</system.runtime.remoting>
</configuration>

Also note that custom errors must be disabled on the server for the original exception to propogate correctly:

<configuration>
    <system.web>
         <customErrors mode="Off" />
    </system.web>
</configuration>

WinForms use of AssemblyInformationalVersion Attribute

2006-02-26T06:58:00Z

The AssemblyInformationalVersion attribute provides a secondary mechanism for versioning an assembly without modifying the value of the AssemblyVersion attribute, thus consumers of an assembly do not need to apply binding redirects or publisher policy when revisions of an assembly are deployed.

Contrary to the documentation:

The attribute defined by this class attaches additional version information to an assembly for documentation purposes only. This data is never used at runtime.

this attribute is referenced by the System.Windows.Forms.Application.ProductVersion static property, which in turn is referenced by the Application.CommonAppDataPath, Application.LocalUserAppDataPath and Application.UserAppDataPath static properties. This is the case for the .NET 1.* and .NET 2.0 class libraries.

If the AssemblyInformationalVersion attribute is applied to the base executable, the ProductVersion property and its dependent properties will use this value instead of the AssemblyVersion attribute value.

Microsoft states that this behaviour is by design.

Writing Well-Factored Code

2005-08-27T12:24:00Z

Coding is a design activity conducted at the lowest level. Similar to analysis and design patterns aiding their respective phases of the software development process, coding patterns exist to aid the implementation phase.

Common coding patterns/techniques include:

Keep methods small, focussing on discrete tasks;
Early exit to reduce nesting;
Use private fields to reduce internal parameter passing;
Use regions as a categorisation mechanism, not to hide code; and
Use internal commenting sparingly.

Keep Methods Small, Focussing on Discrete Tasks

Implementing methods of short length facilitates functional decomposition, making it easier to debug errors and more clearly communicate the intent of code. Consider the following example:

public class Employee
{
    public void DoWork()
    {
        this.ProcessOrders();
        this.TakeBreak();
        this.SweepFloor();
    }
}

Issues associated with this technique include:

Appropriate method length;
Method naming;
Focus on allocation of responsibilities;
Reuse benefits; and
Perceived Performance Implications.

Appropriate Method Length

Well-factored methods should be 5-10 lines in length. If methods exceed this length, then further factoring is required.

There will be instances whereby decomposing methods to achieve this goal does not add value, examples being methods that perform mapping functions or rudimentary validation.

Method Naming

It is imperative to name methods that reflect the intent of the behaviour of the method. Such names should also be kept as short as possible. Appropriate naming of methods significantly reduces the need for internal commenting.

Focus on Allocation of Responsibilities

Decomposing methods into smaller functions, or responsibilities, also makes it easier to see which classes are responsible for what behaviour. Reallocation of responsibilities often results from method factoring. This is a key component of Responsibility-Driven Design.

Reuse Benefits

Factoring methods into smaller functions makes it easier for functionality to be reused/overridden/extended by subclasses. This also avoids the common problem of large methods being copied into subclasses to change a small part of the method, leading to future maintenence issues.

Perceived Performance Implications

Factoring methods into smaller functions implies an increase in the number of method invocations, which can lead to performance concerns regarding the overall increased cost of method invocation. For normal business code, this low-level concern is unfounded.

If you are writing a core function for a framework (similar to the core services provided by the .NET Framework), then the cost of method invocation may become important. To address this issue, profiling of the problem area should be conducted, then act accordingly.

Early Exit to Reduce Nesting

Exiting early from methods reduces nesting and indentation. Consider the following example:

Before:

public class Employee
{
    public double CalculateExpectedBonus(double salary)
    {
        double total = 0;

        if ((salary != null ) && (salary > 0))
        {
            if ((_name != null) && (_name.StartsWith("FRED")))
            {
                total = salary * (_weight / _height);
            }
        }

        return total;
    }
}

After:

public class Employee
{
    public double CalculateExpectedBonus(double salary)
    {
        if ((salary == null ) || (salary == 0))
        {
            return 0;
        }

        if ((_name == null) || (!_name.StartsWith("FRED")))
        {
            return 0;
        }

        return salary * (_weight / _height);
    }
}

Implementing this technique commonly involves reversing logic and reduces the need for temporary variables. Both of these factors are realised in the above example. Guard clauses are the most common application of this technique.

Methods that have a void return type can use a return; statement.

Note that the idea of early exit is somtimes disliked as methods should have one point of exit for simplicitly reasons. This concern is unfounded due to the increased complexity involved in conforming to the single exit principal, as demonstrated by the above (albeit contrived) example.

Use Private Fields to Reduce Internal Parameter Passing

Private fields can be defined to reduce parameter passing between methods internal to a class. Consider the following example:

Before:

public class Order
{
    public void Process()
    {
        ArrayList orderItems = new ArrayList();

        this.RetrieveOrderItems(orderItems);
        this.ProcessOrderItems(orderItems);
    }

    private void RetrieveOrderItems(ArrayList orderItems)
    {
        ...
        SqlDataReader dataReader = command.ExecuteReader();
        while (dataReader.Read())
        {
            OrderItem orderItem = new OrderItem(dataReader);
            orderItems.Add(orderItem);
        }
        ...
    }

    private void ProcessOrderItems(ArrayList orderItems)
    {
         foreach(OrderItem item in orderItems)
        {
            OrderItemDispatcher.Instance.Send(item);
        }
    }
}

After:

public class Order
{
    private ArrayList _orderItems;

    public Order()
    {
        _orderItems = new ArrayList();
    }

    public void Process()
    {
        this.RetrieveOrderItems();
        this.ProcessOrderItems();
    }

    private void RetrieveOrderItems()
    {
        ...
        SqlDataReader dataReader = command.ExecuteReader();

        while (dataReader.Read())
        {
            OrderItem orderItem = new OrderItem(dataReader);
            _orderItems.Add(orderItem);
        }
        ...
    }

    private void ProcessOrderItems()
    {
         foreach(OrderItem item in _orderItems)
        {
            OrderItemDispatcher.Instance.Send(item);
        }
    }
}

As the number of parameters passed between methods increases, so to does the complexity of the code. The use of private fields alleviates this issue.

Note that this technique is sometimes disliked as it becomes more difficult to identify where a given private field is referenced and modified, leading to hidden dependencies between methods. Adoption of this technique is a trade-off for simplicity. Most modern IDEs have reference identification facilities, which further alleviate this concern.

Use Regions as a Categorisation Mechansism, Not to Hide Code

Regions are intended to be used to categorise methods, not to hide code. If the latter is evident, then the code requires refactoring. Common uses of regions include categorisation of Constructors, Private Fields, Private Methods and Public Methods, as demonstrated in my earlier article Implementing the State Pattern in C#.

Generated code is an exception to this rule.

Use Internal Commenting Sparingly

Internal comments should be used sparingly, and only where the intent of a statement is not obvious. Alternatively, the preferred approach is to factor the statement into a method with an appropriate name indicating the intent.

Internal comments that state the obvious do not add value, and add 'noise' to the surrounding code. Consider the following example:

// Add the order item to the order
order.Add(orderItem);

Conclusion

Coding patterns can be applied during the initial development phase and as part of maintenence activities, and ultimately deter the onset of software entropy (a.k.a. Big Ball of Mud software architectures). The adoption of such techniques results in clearer communication that simplifies the maintainability and extensibility of code.

Implementing the State Pattern in C#

2005-07-26T13:45:00Z

Implementing behavior that adapts to changes to the internal state of an object is a difficult task. If not designed correctly, such behavior can contain duplicate/nested conditional logic that is difficult to understand and maintain.

Overview of the State Pattern

The state pattern encapsulates state-based behavior in discrete classes. Responsibilities are identified and delegated to appropriate states, whilst polymorphism eliminates conditional logic, and delegation removes duplication.

Such factoring simplifies logic and ultimately results in code that is easier to maintain and extend over time.

Applying the State Pattern

Applying the state pattern entails:

Defining the state machine, including the states and transitions;
Defining an abstract base class that includes default implementations for all properties and behavior handled by the state machine;
Defining concrete classes for each state which derive from the abstract base class;
- Define properties and methods for each concrete class which override default implementations from the base class;
Delegating to the state machine from the enclosing class.

Consider the following application of the state pattern.

An Example, the Order Class

An Order can be processed (either successfully or unsuccessfully) or cancelled.

Defining the State Machine

The states (including the initial and final states), and the transitions with respect to the Order class are:

States:

New, Processed, Cancelled.

Initial State:

The New state.

Final States:

The Processed and Cancelled states.

Transitions:

Process() = Successful, between the New and Processed states;
Process() = Unsuccessful, both starting and finishing at the New state;
Cancel() between the New and Cancelled states.

The complete Order state machine is as follows:

Defining the Abstract Base Class

The abstract base class of the state machine is defined as follows:

Methods corresponding to each of the state transitions are required. These methods will do nothing by default, and will be overridden by subclasses as appropriate. Each method will accept a reference to an object of the enclosing class as a parameter (the Order class in this example) which they can manipulate if required;
For each state, an associated querying property is required, the default implementation of which will return false;
The abstract base class, and derived classes, should be marked as internal as they are only intended to be accessed by the enclosing class.

The abstract base class for the Order example will be called OrderState, the implementation of which is as follows:

    internal abstract class OrderState
    {
        #region Public Properties

        public virtual bool IsNew
        {
            get { return false; }
        }

        public virtual bool IsProcessed
        {
            get { return false; }
        }

        public virtual bool IsCancelled
        {
            get { return false; }
        }

        #endregion

        #region Public Methods

        public virtual void Process(Order order)
        {
        }

        public virtual void Cancel(Order order)
        {
        }

        #endregion
    }

Defining the Concrete Subclasses

Concrete subclasses for each of the states are defined as follows:

Each subclass is implemented as a singleton, and does not maintain state for thread-safety reasons. See Implementing the Singleton Pattern in C# for an in-depth discussion of thread-safe singleton implementations.
Each subclass overrides the appropriate querying property to return true;
Each subclass may override the state transition methods to perform desired behavior. These implementations will also reset the current state of the object of the enclosing class (which is the main reason the object reference is provided).

The concrete subclasses for the Order example are called OrderNewState, OrderProcessedState and OrderCancelledState, the implementation of which are as follows:

    internal class OrderNewState : OrderState
    {
        #region Private Fields

        private static readonly OrderNewState _instance = new OrderNewState();

        #endregion

        #region Constructor

        private OrderNewState()
        {
        }

        #endregion

        #region Public Static Properties

        public static OrderNewState Instance
        {
            get { return _instance; }
        }

        #endregion

        #region Public Properties

        public override bool IsNew
        {
            get { return true; }
        }

        #endregion

        #region Public Methods

        public override void Process(Order order)
        {
            bool success = false;

            // Do Processing...

            if (success)
            {
                order.State = OrderProcessedState.Instance;
            }

            base.Process(order);
        }

        public override void Cancel(Order order)
        {
            order.State = OrderCancelledState.Instance;
            base.Cancel(order);
        }

        #endregion
    }

    internal class OrderProcessedState : OrderState
    {
        #region Private Fields

        private static readonly OrderProcessedState _instance = new OrderProcessedState();

        #endregion

        #region Constructor

        private OrderProcessedState()
        {
        }

        #endregion

        #region Public Static Properties

        public static OrderProcessedState Instance
        {
            get { return _instance; }
        }

        #endregion

        #region Public Properties

        public new bool IsProcessed
        {
            get { return true; }
        }

        #endregion
    }

    internal class OrderCancelledState : OrderState
    {
        #region Private Fields

        private static readonly OrderCancelledState _instance = new OrderCancelledState();

        #endregion

        #region Constructor

        private OrderCancelledState()
        {
        }

        #endregion

        #region Public Static Properties

        public static OrderCancelledState Instance
        {
            get { return _instance; }
        }

        #endregion

        #region Public Properties

        public override bool IsCancelled
        {
            get { return true; }
        }

        #endregion
    }

Delegating to the State Machine from the Enclosing Class

The enclosing class with which the state machine is associated is defined as follows:

A private field of the same type as the abstract base class must be defined;
An initialisation method (typically the constructor) must set the private field to the initial state;
The state transition methods and querying properties previously defined for the abstract base class must be defined, which delegate to the private field. The implementation of the state transition methods must pass along a reference to the enclosing class (i.e. the Order);
An internal property state setter must be defined so that the concrete state subclasses can reset the state of the enclosing class as appropriate.

The Order class is as follows:

    public class Order
    {
        #region Private Fields

        private OrderState _state;

        #endregion

        #region Constructors

        public Order()
        {
            _state = OrderNewState.Instance;
        }

        #endregion

        #region Public Properties

        public bool IsNew
        {
            get { return _state.IsNew; }
        }

        public bool IsProcessed
        {
            get { return _state.IsProcessed; }
        }

        public bool IsCancelled
        {
            get { return _state.IsCancelled; }
        }

        #endregion

        #region Internal Properties

        internal OrderState State
        {
            set { _state = value; }
        }

        #endregion

        #region Public Methods

        public void Process()
        {
            _state.Process(this);
        }

        public void Cancel()
        {
            _state.Cancel(this);
        }

        #endregion
    }

The Complete Order Class Model

When to Use the State Pattern

The state pattern can be used when there is significant state-based behaviour associated with a class.

In other cases, continue to use conditional expressions (typically, with the aid of enumerations).

Further Uses

The above techniques are also applicable to implementation of the Strategy pattern. Implementation of the State and Strategy patterns is exactly the same, however, the intent of each pattern is different. The State pattern is used to model finite state machines, whilst the Strategy pattern is used to implement pluggable algorithms. Note that implementation of the Strategy pattern may not require querying properties.

Source Code for Examples

A Visual Studio .NET 2003 solution containing the above example code can be downloaded here.

Greetings

2005-07-26T13:27:00Z

I'm Matt Dunn, a twenty-something IT professional based in Canberra, Australia.

My intent is to illustrate solutions to software development issues, focussing on Object-Oriented software development, with examples primarily implemented in C#.

Enjoy!