I have always maintained an interest in workflow, and on a few occasions have been able to put it to use productively on some of my projects; from a good few years ago implementing WF as a web site process controller (see my post here on integrating WF with ASP.Net MVC), to a few months ago giving public presentation around the improved integration between WF and WCF in Net 3.5 (Send/Receive activities) at my current employer's regular community events.

Well, from reading the lead article in this month's MSDN magazine (and between-the-lines of some of the material released at this years PDC (start here for good overview)) it seems that when .Net 4.0 arrives WF may finally be reaching a level of maturity to justify a more mainstream role in the .Net world.

• There is a new WCF/WF integration model. Although only a year or so old, it seems the Send/Receive activities are to be little more than a stop-gap solution and will be replaced with new richer SendMessage/ReceiveMessage activities.
• The concept of WCF hosted workflows which was released in 3.5 is to be developed to a level it will now be possible to define both the workflow and the service and message contracts from within the workflow Xaml itself, reducing a good degree of redundant boilerplate code/configuration.
• The WF designer within Visual Studio is to be rewritten (hopefully withpout as many frustratingly erratic  bugs) to support this new functionality and to enhance the debugging experience of Xaml-only workflows.
• There is an update to the Server 2008 'Application Server' role (currently codenamed Dublin) in the pipeline which will add integrated management and tracking of workflow instances hosted within IIS.
• ...and probably most revolutionary of all - as the mechanism by which azure provides code execution in the cloud - hosted workflows may finally be the 'killer app' that forces otherwise ambivalent developers to take a fresh look at the technology as a means to solve their problems.

On the downside, though:

• The new flowchart workflow process model and various other activity execution model changes seem that they will require breaking backward compatability with custom activities written for .Net 3.5 and before. Although for those of you yet to make any significant investment in custom activities this may be hit you don't even notice.

Obviously much of this technology is at the announcement or early CTP stage, but I would seriously recommend reading the couple of articles in this month's MSDN magazine, downloading the PDC VS2010 CTP (including .Net 4.0), checking out registering for a trial account at the azure site and generally keeping your eye on WF over the next 12-18 months.

For the last 2 months (and until end of January next year) I have been working as Build Manager on a relatively large, and potentially high profile (when all the NDAs expire), project in the Solution Development Centre at Microsoft in Sydney.

Many of my friends have been asking all the obvious questions such as: What's the product I'm working on like? Who is the client? When will it go live? But also how projects are run internally at a large and professional outfit such as Microsoft. Well the time for me to tell all is not now, however, I can point to a post (here) by the Solution Architect of the project explaining how things are run on a daily basis.

Some of the early stuff I can't comment on, as I only joined the project mid-way, but the post is an accurate reflection of what happens here everyday; ie of a pragmatic and effective way to run a significant quality driven project in the face of complex and competing requirements.

I was reading this month's Microsoft Architecture Journal on the train home today when I came across this little nugget at the end of one of the articles...

Head in the Coud, Feet on the Ground, Microsoft Architecture Journal 

LOtSS* uses the cloud as an optimization opportunity driving overall costs down. Although this “faster, cheaper, better” view of the cloud is very important and is likely to be a key driver of cloud utilization, it is important to realize that it is only a partial view of what the cloud can offer. The cloud also presents opportunities for “not previously possible” scenarios. IT history has shown that over time, what was unique and strategic becomes commodity. The only thing that seems to stay constant is the need to identify new optimization opportunities continuously by selectively replacing subsystems with more cost-effective ones, while keeping the cost introduced by the substitute low. In other words, it seems that one of the few sustainable competitive advantages in IT is in fact the ability to master LOtSS.
* 'localized optimization through selective specialization'

...what struck a chord with me has nothing to do with cloud computing. But how relevant this statement is to exactly what skills are worth investing in during one's career. <insert latest hyped technology> may be the big thing now - and command big bucks for those who know it inside out - but the most sustainable career growth strategy in IT is an investment in developing the analysis skills that allow you to cut through to the real value in any technology, and the communication skills to be able to express this effectively to your customers and clients.

Background

As part of my current project we track and reporting on a number of source metrics (average/max methods per class, average/max calls per method, average/max cyclomatic complexity etc..) on a daily basis.

Unfortunately, as we are running Visual Studio/Team Foundation 2005 we are unable to use the built in metrics (and hence the integration with TFS) and so have fallen back to using an external product which has been filling this space for a long time called Source Monitor.

Anyway, when I joined the project this tracking was being done manually; a daily routine was in place where someone would...

• Perform a local get of the latest source.
• Check out the Source Monitor .smp project file.
• Open this and create a new check point (which for our code base takes a couple of minutes).
• And finally export the results as xml before running an xslt to generate html for pasting into an email for circulation.

Well, as we are running a pretty tight continuous integration ship (yes we had to build our own CI notification on top of VS 2005), this struck me from day one as an obvious candidate for improved automation. Today I finally got the few hours it took to knock up a custom MSBuild task to do the job.

Note: I honestly didn't want to go to this level of effort, but Source Monitor requires an 'instruction' file to be generated when executing at the command line and having searched the web, was actually surprised to only find a few examples of doing this. Most of them were very much CruiseControl or Nant focussed.

Implementation

The actual implementation takes its inspiration from these two posts (Dan Rigsby / Robin Curry), but instead of placing all the logic directly within xml, tries to encapsulate as much of the ugly glue into the c# implementation within the task… hopefully simplifying and improving the maintainability of the actual calling build script.

The task itself derives from ToolTask. It adds 3 properties (2 of which are 'required'):

• ProjectFile (Required): The path of the .smp file to execute Source Monitor against (you should create this interactively using the Source Monitor interface). 
• SummaryFile (Required): The path to write the Source Monitor summary report (in xml format).
• CheckPointName: The name to give to the new checkpoint within the project (If this is '' or omitted Source Monitor will use its own logic to name the checkpoint).

The following properties (inherited from ToolTask) are also relevant:

• ToolPath: The optional location to find SourceMonitor.exe (defaults to 'C:\Program Files\SourceMonitor\')
• ToolName: The optional filename of SourceMonitor.exe (defaults to 'SourceMonitor.exe'  - you should only need to change this if a new version of the tool changes the exe name)

Usage

So, the source to the task is attached in the zip file below (you will need to install Source Monitor separately yourself from here). Also included in this is a demonstration MSBuild .proj file (the next best thing to some proper unit tests) – hitting F5 from within Visual Studio will run this in debug, and it will generate a summary and details report on its own source code! If you simply want to use the task as-is within TFS server build then you will need to compile it then make the following changes to your build script:

• Copy the binary dll to: C:\Program Files\MsBuild\MSJ.MSBuildTasks.dll (or anywhere else, but this easily accessible from within scripts using the built-in $(MSBuildExtensionsPath) variable).
• Reference the task at the top of your script:

<UsingTask AssemblyFile="$(MSBuildExtensionsPath)\MSJ.MSBuildTasks.dll" TaskName="SourceMonitor" />

• Call the task at an appropriate point (obviously this must be after the source is downloaded); I personally prefer BeforeCompile:

Note: As we store the Source Monitor project in source control, we must check this out to make it writeable before we execute the task (Source Monitor needs write access to add the new checkpoint).

<PropertyGroup>

    <!-- TF.exe -->

    <TF>&quot;$(TeamBuildRefPath)\..\tf.exe&quot;</TF>

    <SourceMonitorProjectFile>$(SolutionRoot)\SolutionProjectFile.smp</SourceMonitorProjectFile>

</PropertyGroup>

<Target Name="BeforeCompile">

<!-- Check out Source Monitor project (it needs to be writeable to add new checkpoint). --> 

    <Exec

        WorkingDirectory="$(SolutionRoot)" 

        Command="$(TF) checkout "$(SourceMonitorProjectFile)"" /> 

        <!-- Execute Source Monitor to add new checkpoint (named after the build number) and export summary/detail reports as xml. --> 

        <SourceMonitor 

            ProjectFile="$(SourceMonitorProjectFile)" 

            SummaryFile="$(SolutionRoot)\Build Reports\SourceMonitorSummary.xml" 

            DetailsFile="$(SolutionRoot)\Build Reports\SourceMonitorDetails.xml" 

            CheckPointName="$(BuildNumber)" 

            /> 

    <!-- Check in Source Monitor project with new checkpoint (use /override flag to avoid check-in policy issues). --> 

    <Exec

        WorkingDirectory="$(SolutionRoot)"

        Command="$(TF) checkin /comment:"Build script auto update" /noprompt /override:"Build script auto update" "$(SourceMonitorProjectFile)"" />

    <!-- Run xslt batch file against xml or anything here… --> 

</Target>

Note: If you install Source Monitor to a non default location (or you are running on a 64 bit server like us) you must specify this using the ToolLocation attribute:

<SourceMonitor

    ToolLocation="C:\Program Files (x86)\SourceMonitor\" 

    ProjectFile="$(SourceMonitorProjectFile)"

    ...

    />

Download:

• Download the source to this post (VS2005) from here: MSBuildTask.zip (4.95 kb)

Just back at work for the first (well second, but first productive day) and working through my blog backlog when I found this moderately amusing mock ikea manual (original post here).

A few years ago I was responsible for selecting the WCSF (Web Client Software Factory) as the architecture for a website for one of my clients; at the time it was 'the' MVC based framework being touted most heavily by Microsoft.

Although it eventually turned out to be a mixed experience over the life of the project (particularly the Guidance Toolkit aspect), the feature that caught my eye when choosing it was the use of WF state machines as an underlying navigation management framework. This seemed particularly appropriate for the project as the previous version of the website had suffered badly from poorly implemented and unmaintainable navigation (the site presented multistage applications for financial products with complex dependencies between data and the order and display of pages).

Anyway, to paraphrase the 15th century French, 'WCSF is dead. Long live Asp.Net MVC!' So with this in mind, I thought I would see how easy/useful it would be to re-implement the use of WF as the basis of a generic 'wizard' MVC controller - separating the responsibility for all navigation to an underlying workflow.

At first I planned to use a standard state machine workflow wrapped in an MVC Controller class in the same way the WCSF had worked - but then I remembered Matt Winkler's Pageflow sample. This was a specialised workflow type designed explicitly to model navigation graphs and released informally through his blog back in mid 2007 (sadly too late for my first project).

So, after downloading and re-familiarising myself with this, I set about coding a generic MVC Controller class that would support the standard multi-step actions we all expect in wizards (Start/Resume/Previous/Next/Abort) by delegating the required view selection logic to an instance of a Pageflow workflow. To make this vaguely realistic, I decided that anything I wrote had to be able to reproduce 'Workflow1' sample included with the download of the Pageflow bits (a 6 page (with two data driven steps) helpdesk request example). I also restricted myself to referencing the Pageflow DLL (Microsoft.Samples.Workflow.UI.dll) without recompilation.

Here is what I came up with:

MvcPageflow.csproj

This class library is the crux of the solution and where all the Pageflow to MVC logic resides, in particular:

• The WorkflowWizardController class contains the majority of the code. It is a generic class (parameterised by a Pageflow derived type) that defines the actions described above and handles all the necessary communication with the Pageflow instance.
• The WizardControllerViewData (internal) class. This is passed to all views (which are defined as ViewPage<Workflow1Controller.WizardControllerViewData> to allow them to enable/disable various navigation options and to receive the output of the previous Pageflow transition.
• The HttpCookieWizardContextManager class which is the default implementation for handling the correlation of client requests and Pageflow instances (see below).
• EnhancedBookmark class which derives from the original Bookmark class by adding IsStartingActivity/IsTerminatingActivity properties necessary for the population of similar properties passed to the view.
• EnhancedNavigationManager again derived from the equivalent NavigationManager class adding extra methods for working out the IsStartingActivity/IsTerminatingActivity info for each stage.

Note: The two final classes are certainly not the most elegant implementation and are only necessary as a result of my self imposed restriction to maintain binary compatibility with the original Microsoft.Samples.Workflow.UI.dll.

MvcSampleWeb.csproj

A standard MVC web project with:

• A Workflow1Controller (derived from WorkflowWizardController with a few logic specific methods overridden).
• 6 simple views (copied in layout from the Asp.Net pages of the original sample) and with Previous/Next/Abort links enabled based on the ViewData passed to them.
• An edited Index view with links to Start/Resume a Workflow1Pageflow process and some explanatory text.

MvcSamplewebPageflow.csproj

A a standard workflow class library containing:

• Workflow1.xoml - the unaltered Pageflow (modelling a helpdesk request) from Matt's original Asp.Net sample.

Note: I actually started off with Workflow1.xoml in the same folder as the Workflow1Controller class in the MVC web project, but the WF designer continually crashed until I placed this in a separate assembly.

MvcSampleWebTests.csproj

This is a standard VSTest project that contains a few rudimentary tests which exercise the Workflow1Controller, checking all the views are transitioned to in the correct order and that the Resume and Abort actions work/throw appropriately.

Note: The the 'fake' context/request/response test helper classes are extracted as-is from here.

In Summary:

So exactly how hard was this, well not very hard at all. The only really interesting/difficult decisions were:

Instance Correlation: As we all know, the browser/server interaction is essentially stateless, yet state machine workflow's are fundamentally stateful so how do we reassociate a client's request for a relative action such as 'Next' with the correct Pageflow instance (which maintains the knowledge of which state Next is to be applied to). Well, the original Asp.Net example used cookies and so do I. Although for you IoC fans out there, this is factored into an interface (IWizardContextManager) and made a Controller constructor dependency for easy substitution.

Pageflow/View Communication: The original sample had a reaonably tight coupling between the Pageflow and the pages (as is the way with traditional Asp.Net). One of my goals was to write a reusable base Controller which could be derived from and used to model more than just trivial Next,Next,Next processes. If, like the Workflow1 example, these required branching logic within the Next transitions based on user entered data there needed to be an easy way to pass this into/and out of the pageflow. The solution I came up for output data was simple, make it a property on the ViewData class passed to the views. For the input data, which would vary from view to view, I added a virtual GetWorkflowInputData() method that can be overriden to provide any data into the workflow at each action. This can be seen in action in the Workflow1 controller which simply returns the appropriate request form fields depending on the view; these are then used internally by the transitions on the EnterAlias and EnterProfile Pageflow InteractionActivities to decide which activity (and so view) comes next.

Future Areas for Improvement:

WorkflowRuntime: WF requires Pageflows (as with all workflows) to run in a single instance of the runtime configured with the appropriate services. Purely for ease of coding the download currently stores this in a static field of the WorkflowWizardController - this would be better placed in the Application object. The configuration of this runtime is also currently hardcoded (see download instructions) and should be more configurable.

Download:

If you are interested in getting this to work on your machine you will need to:

• Download and install (to default location) Asp.Net MVC Preview 3 from here.
• Download and install (to default location) the Pageflow sample from here.
• Download and extract the source to this post (and open in VS2008) from here: MvcPageflow.zip (65.67 kb)

You will also need to have setup a persistence service SQL database (this page has a paragraph on how to do this) and update the connection string in WorkflowWizardController static constructor (I know this should be read from the web.config).

Last night I gave a short technical presentation in Sydney at one of my employer's monthly customer marketing events. Nothing too fancy, 30 minutes on 'What's new in Windows Workflow (WF) in version 3.5' to about 60 people.

However, the choice of topic and slides weren't my own (credit: Chris Padgett); also some time in the afternoon I started coming down with a mild case of the perennial winter nose/throat infection (I am on the cold & flu today) and I was feeling pretty nervous as a result of it being over a year since I formally stood up in front of a group bigger than 1...heading for a train wreck, or so I thought...

As it turned out, the event didn't go too badly (no disastrous demo crashes or even (noticeably) bad pauses) but then again, I still haven't seen the collated feedback forms; and either way I was still outclassed in both material and presentation by my colleague who followed me with an excellent presentation on production debugging.

Anyway, the most important thing to remember is that these things are never quite as bad as you think!

As you can see have I have added a Google Map to my blog.

In less than 30 mins (15 of which was spent looking up the right CSS class for the brown border in the theme folder) I now have a nice little embedded map showing my location over my next trip. This was remarkable easy to create. As soon as I went to maps.google.com (whilst logged in to my gmail account) there was an immediately obvious link to 'my maps' which took me to a simple, responsive and intuitive interface for pushpins/lines/areas the lot.

However, despite this easy set up you'll see my map does have one disappointing aspect to it - zero coverage of North Korea - for whatever political reasons (although I can find no explicit mention why it is omitted) Google does not acknowledge the existence of any civilisation in the DPRK. However MS Live Maps does; now what prevents one and not the other (both US companies, in identical legal situations) from showing what is obviously available information (every paper atlas I have ever seen has Pyongyang marked) I can only guess.

So after a little more research I discovered that Live Maps have just added support for Google's KML, now along with the ability to return the KML from any Google My Map I can pipe these two together (check the second link) to have my pushpins shown on either map (Google for the world, and Live for when I am in DPRK).

Technical details from TechCrunch here.