For this post, I’m going to use a small example task – parsing a file on disk and summarizing some information from it. In this case, we’ll do something simple – read a CSV log file of “events” that occurred, and get the range of ID numbers from the file. Here is our input file:

Our task will be to read this file, parse it, and get the range of IDs being used. In this case, we’ll end up with 2 numbers as our result – 1928 and 1939.

When working in F#, I often start by describing the data I’ll be using, as well as the result I want to get or manipulate. Here, each row represents three things; a date, an ID, and a description of the event. We want to eventually get two numbers, a starting ID and an ending ID. In addition, we know there are a few things that could go wrong – the file might not exist, there might be no data in the file, or the data might be malformed. I’m going to start by defining a couple of types to help with this:

My goal when writing this utility will be to always write in a “happy path”. Instead of focusing on handling bad data or errors, I’m going to try to break everything up into small steps, each a function, that does one thing. I’m always going to assume my inputs are good, and my output will always either be good result or an Issue from above. Basically, I never want to think about “bad data” – I just want to write code that does something as I go.

In F#, there is a type that helps with this significantly – Result. The Result type is a discriminated union with two options; an Ok result, or an Error.

We’ll start by opening our file. In this case, we want a function that takes a filename and returns a Stream we can use for reading. File IO is one place where exception handling is nearly required, so I’m using that to create my error case:

This function will follow a common pattern – it takes an input (filename) and creates a Result: val openFile : filename:string -> Result

To parse the file, I’m going to use the CsvHelper library. This will allow me to not think about parsing the “hard parts” of CSV, like strings with embedded commas or quotes. Now we need a small function to take a stream from our openFile and convert it to a CsvReader:

Here, we know, if we have a valid stream, we’ll get a valid reader, so we can just write a simple Stream -> CsvReader helper. We can put these together with Result.map, which allows us to take an “Ok” result and use it’s value to make a new result.

Running in FSI, with a good filename, gives us val csv : Result = Ok CsvHelper.CsvReader. With a bad filename, you get:

val csv : Result =
Error
(IO
("Could not open file",
System.IO.FileNotFoundException: Could not find file…

Now that our file is opened, we can move onto parsing. Again, we’ll assume we have a good input (our reader), and just write routines to just parse. In this case, I’m going to write a function to parse a single row and create an option, and a separate function to parse until we receive None, which will return our Result.

This does get a little uglier with the routine to read all of the rows. We want to make sure to close our file (we effectively pass ownership), so we need the try/finally to dispose of it anytime our routine to open succeeded. We’ll use a simple try/with to handle parsing errors. Using Seq.initInfinite and Seq.takeWhile allows us to “loop” through our data until we return None:

Our final step is to reduce the Event list to our two numbers:

Now that we have all of the pieces, we can stream these together. We will use two functions from the Result module in the core libraries to string these together – Result.map and Result.bind.

Whenever we have a function that doesn’t produce an error case, we will use map. When we have a function that takes our input and might need an error case, we will use bind. In our case, openFile and getIds both “always work” if their input are good, so we can map them. readRowsAndClose can map the data through to a list, but can also create an error case, so we will use bind. When stringing these together, we end up with:

When run via FSI, and given the input file above, this now produces:

val result : Result = Ok { Start = 1928
End = 1939 }

If we pass an invalid filename, we get a nice error:

val result : Result =
Error
(IO
("Could not open file",
System.IO.FileNotFoundException: Could not find file...

If we pass a good filename, but the file has bad data, that is also handled:

val result : Result =
Error
(DataMalformed
("Unable to parse data",
CsvHelper.TypeConversion.TypeConverterException: The conversion cannot be performed.
Text: '193d3'

By breaking this into pieces, and using Result.map and Result.bind, we were able to parse this in stages, where every stage could assume everything was “good”, and our errors propagate through cleanly at the end. Each step in the chain only has to focus on the task at hand.

People coming to F# from other languages frequently find themselves copying the idioms of their past, and struggling with how to have things make sense in F#. Loops are a very common example.

A common thread in these discussions which seem to cause difficulty is “looping to generate a result”. This can be seen easily in the C# tutorial’s looping code. Here, a mutable value is created to hold some result (sum), a for loop iterates through a bunch of numbers, logic is placed in the loop body that mutates the value, and the result is used afterwards. While this can be ported to F# directly, it tends to be ugly in the end, as it relies on looping and on mutation.

I frequently suggest that people new to F# should strive to reduce mutation as well as code which relies on side effects (every loop body does), but confusion frequently occurs with cases like this. Recursion is frequently suggested as a solution, but its far from simple in many cases, especially when people are just starting out.

So let’s rework this a bit – and lets start small by reducing mutation. First off, we can refactor the “logic” portion of this into a function and make it pure. In this case, we want a function which will not mutate a value, but instead, return a new value each time it’s run, passing the existing input into it.

Doing this allows the “logic” to be much more easily tested, but is also an important first step. We can then remove another point of mutation – the for loop itself, by switching to a foreach loop over a sequence:

It’s typically at this point where people get stuck. Its far less obvious to see how we remove the mutable value which holds the result. Before we move forward with removing the mutation, lets port this to F#:

While this is obviously more succinct, it does exactly the same thing, using the same imperative techniques as before, at least in the core loop. In preparation to eliminate the mutation, I’m going to make this less succinct, so the intention behind what is occuring becomes more obvious.

While this does the same steps as the previous version, each temporary value is broken out into a binding, so the intent and process becomes more clear. However, we still are using a mutable to hold and mutate state each step.

Enter fold.

If we look at Seq.fold, we see that it has the following signature:

This function takes a function as input, which takes the previous state, the current value, and returns the new state. That is remarkably similar looking to our factoring of addNewConditionally – it takes the last value, the current value, and returns the new value. It also then takes a ‘State value – which is the initial state used for the first item being processed. Finally, it takes a sequence to operate over, and then returns a result at the end after processing each item.

In our case, we have all three of these, so we can easily rewrite our loop as a fold:

Note that this eliminates the need for a mutable value – each step works on the previous result, and returns a new value. We can now remove all of the temporaries, and rewrite this much more simply:

This gives us a simple, clean way to handle this example.

On a side note, in this particular case, the result type and input collection are all int values, and the initial value is the default value for int (0), so we have other, potentially simpler options. We could use Seq.reduce instead, or a Seq.filter piped into a Seq.sum. However, looking back at fold, one benefit is that the ‘State type is separate from the input type ‘T. This means we can use a fold to replace any loop that is used to generate results based off the items being looped over, even if the types don’t match.

As a simple example, lets say our requirements change. Instead of just needing the sum of the values that meet our criteria, suppose we want to generate a list of the values as strings. All we need to do is change our function to work on and return a string list, and to change our initial ‘State value.

This works the same way, but now we go from int seq to string list instead of to an int as our result.

While these are fairly simple and contrived examples, the approach taken here works for moving from any loop that generates “results” to a fold:

• Make core logic a pure function (which can be a lambda expression) – which takes the previous result, the current value, and return a new state
• Rework items being “processed” into a collection or sequence if using a “for” style loop
• Remove the mutable “running value” and the loop, and replace with a call to fold

For those familiar with last year’s Christmas Trees application, I wanted to start by saying I’ve only made two simple changes to the logic portion of that application, one by choice, one to make Avalonia function a bit better.

Since Avalonia is intended to run on multiple platforms, I thought it would make sense to simplify the interface. In previous years, I had separate logic for right and left mouse click events, which isn’t very friendly on Mac or mobile. To handle this, I thought I’d add a single “DecorateOrLight” command that would automatically toggle the decorated and lit state of the trees every time you clicked/tapped on a tree instead of having two separate operations.

Given the MVU approach Gjallarhorn uses, this was very simple. All I needed to do in the Tree handlers was add a single new case to the message, and handle it:

I also needed to modify the program in 2 places to add Commands to handle this new message:

Once the design time support had this command, it was just a one line addition to bind this to a new command for the view layer.

The other change made to the logic portion was changing the Forest type to accept a Location option instead of a Location for adding new trees. In the WPF application, I was using some special FsXaml helpers to filter out “None” values, but the default XAML tooling doesn’t support that. Instead, I’m now filtering out None values in the Forest update method and leaving the forest unchanged:

While this is a bit more code, it makes the logic not rely on WPF/FsXaml specific helpers. The WPF application only required on change (remove the filter-by-option setting from XAML) to work again.

Once these changes were in place, I was able to do the fun part – wire this up to Avalonia instead of WPF.

To get that working, I just made a new .NET Core application, and added Gjallarhorn.Bindable.Avalonia as well as some helper routines (XAML Behaviors for Avalonia, etc). The XAML from WPF was copied then modified to work with Avalonia’s structure. While it is mostly unchanged, there are some differences in Avalonia from WPF to handle. I also added an App.xaml as this is expected by Avalonia.

With this done, the startup code in Gjallarhorn.Bindable for Avalonia is very similar to WPF. I modified what was used in WPF:

To make this work in Avalonia, I do the avalonia configuration, then use a slightly modified version of the original WPF code:

With this in place, we can now run and make Christmas Trees using Avalonia!

Even better, since this uses Avalonia and .NET Core, the same code works cleanly on other platforms. For example, here is the same code running on a Mac given nothing but a clone and dotnet run (and a special thank you to @ChetHusk for cloning and running this for me):

This post will modernize the Christmas Tree application from last year, improving it, and highlighting the changes in Gjallarhorn, showing the dramatic improvements inspired by great projects like Elmish. My hope is that more developers will see the benefits of unidirectional architecture for UI development, and try using Elmish for web, Gjallarhorn for XAML, or other unidirectional, functional approaches to user interfaces.

Over the last year, Gjallarhorn has matured greatly. Earlier this year, the project reached the version 1.0 milestone, and the user interface framework was split off into it’s own project – Gjallarhorn.Bindable. Gjallarhorn.Bindable has taken inspiration from Elmish, and developed a newer, simpler API, which adds significant benefits.

The new API has been driven with a few distinct goals in mind. First off, we wanted to simplify the code required. We also wanted to improve type safety and eliminate magic strings whenever possible. Finally, many new scenarios have been enabled via the new navigation API, which allows applications to cleanly work with multiple windows, views, and more.

That being said, the model and message types, and update function, are completely unchanged. The changes all relate to the binding components and application framework setup.

The first major change in migrating to the new API is the addition of a “view model” type. This is a simple type (currently typically a record) used for multiple purposes – it enables design time data for the XAML designer (with type and error checking, intellisense, and more when using Resharper), it eliminates the magic strings in code, and it adds type checking to the binding generation. The “View Model” type is simply a record with one field per binding, used to create an instantiated binding of that record type. For example, our Tree binding from last year is now augmented with the following “VM” type and binding:

The VmCmd type here is provided by Gjallarhorn.Bindable, and allows you to represent a typed message which will be sent back to the update function. Any command bound to the view will be represented this way.

One side note: the current design for the VM was created with the proposed anonymous records kept in mind. If implemented as currently proposed and approved in principle, anonymous records will, in most cases, eliminate the need to create the VM as a type – a simple binding with an anonymous record will work, making this a one-line addition over the previous API.

Once the VM binding exists, it can be used via the new Gjallarhorn API to create our binding much simpler than the previous mechanism. Previously, the tree component was created like so:

With the new VM and new API, this is significantly simpler:

Note that the magic strings used before have been replaced with quotations. In addition, the types defined in the VM are used to type check the bindings directly. We also no longer need to worry or think about the internal types in Gjallarhorn – the BindingSource and ISignal types are eliminated, and we directly specify a mapping from the model type to the bound value type as a simple function (in this case, id, as we’re binding the model directly).

(The unit generic type here refers to the Navigation types – as we are not enabling any navigation messages, I’m passing unit through this everywhere, to effectively ignore the navigation options.)

Our Forest component gets the same treatment:

In addition, the main “Application” components have been simplified. In last year’s version, we managed state ourselves. An AsyncMutable<‘a> from Gjallarhorn was manually created to hold the application state, and an initialization function started an infinite loop to externally update the model state as needed.

The new API simplifies this. The application now takes an initial state, and external updates are now managed via formalized patterns and types defined in the framework. For our pruning routine, instead of directly manipulating the global model, we now create a function which can produce and dispatch messages via a Dispatch<‘a> type passed in, which is simply a function that’s ‘Msg -> unit.

With this, we can create an “Executor” – which is a Gjallarhorn type which can be used to start and stop asynchronous, external (unrelated to the UI) operations. The application framework is dramatically simplified – instead of managing state, we just pass in the initial state, update, view component, and navigation dispatcher (unused in this application). We then attach our executor, and the framework takes care of all of the state management in a thread safe, clean manner:

Not only is this far simpler and more concise (7 lines of code vs 25), it eliminates most of the major potential for mistakes. The focus moves away from working with types defined in Gjallarhorn (mutables and signals) to focusing on the model, message, and update function. External operations can be attached easily, in a predictable manner. The same pattern also allows for logging and other scenarios to be managed in a formalized, simple manner.

The final change required to update this application is in the WPF project. Gjallarhorn.Bindable now supports navigation, which requires some minor changes. Our new entry point function is now:

For this application, we’re working in a single view in an single application, so we’re using the predefined “singleView” navigation type, and unit for the navigation message type. However, the framework supports other navigation types, including single page apps, and fully extendable, customizable navigation enabling multiple windows, each with multiple views, and other scenarios previously difficult to manage with unidirectional architectures.

When run, the new updated version produces the exact same runtime behavior as last year, but now our code is simpler, type safe, and focused more on our domain types and less on the framework enabling the user interface.

Please feel free to clone the repository, try the application, and play with the new and improved framework. Gjallarhorn is still evolving, but now provides a clean, cross platform, unidirectional approach to developing programs based on XAML platforms.

I also recommend reading the other 2017 F# Advent posts being written by the amazing F# community!

This post will modernize the Christmas Tree application from last year, improving it, and highlighting the differences between a classic MVVM approach to WPF and a more functional approach.  While reading through the post from last year would add context, it’s completely optional.

As always, I’ll begin with a brief introduction to the model.  I’ve taken the model from last year mostly as-is, except simplified it and made it more “idiomatic F#”.  This year, I broke out the model for a Tree into its own file:

The actual Tree type is unchanged – but I’ve created the functions to create a new tree and update an existing tree, and placed them into a module for working with trees.  This isolates the types and logic for dealing with a single tree into its own testable portion of the application, and is simple, easy to follow, and easily extensible.

The model for a Forest has received similar treatment:

The main differences when compared to the version from last year is that the logic is now contained in a module, and the message type for updating a forest is dramatically simplified, and now has three options – it can add a new tree, given a location, prune the existing forest if it’s larger than a given size, and update a tree given a TreeMessage and a Tree.  The logic for these just calls into the Tree module when appropriate, making this far easier to understand and extend in the future.

The code up to this point is completely “pure F#” – no external libraries are required, and everything is self contained, testable, immutable, and easy to reason about.  I have a Forest comprised of a list of Tree records, with functions performing updates that returning a new Forest.

Up to this point, what I have is very similar to what I had last year, just slightly more organized, with the Tree having its own module isolating its own logic.

However, this is where things start to change.  In order to wire this up to a UI, there are a few options.

I could go with a naive, just “build out the controls and wire up everything in code” style.  This would work, but tends to lead to a mess of spaghetti, lots of brittle event handling for changing the views and pushing back state, and other issues.  It becomes even more of a mess when considering the fact that the model is represented by a collection – hand-wiring events for managing collections is difficult to get correct, and typically requires a lot of code.

I could go with a classic MVVM approach: this would likely require making a “view model” class to represent a forest and another to represent tree, adding logic in the tree for whether it should be decorated, and adding some mechanism, typically either custom events or a messaging service, to notify the main view model that a tree is updated, wiring up the logic to map to and from the (immutable) model classes, and the like.  Realistically, the boilerplate required to do this would be far more code than I’ve written for the actual application so far – with the collections becoming the most difficult aspect.  Libraries like ReactiveUI or DynamicData can simplify this, but it still is effectively copying the model (manually) into a custom collection of view models, managing them, and manually constructing the model back from the results.

My approach last year was to use FSharp.ViewModule’s EventViewModelBase and custom converters to manage some of this complexity.  That worked quite well – and I was happy (mostly) with the approach, but even so, I ended up creating a custom view model class, two MailboxProcessors to manage synchronization, and a lot of care had to be taken to make sure to always marshal back onto the UI thread before touching the collection (or you get exceptions from WPF) and similar “gotchas” that really are completely separate concerns from my core logic.  At its core this approach still uses an MVVM philosophy for its architecture, though it has a much more functional slant which does help tame some of the complexity.

MVVM, while the most common architectural pattern for dealing with WPF, has some fundamental flaws.  At its core, MVVM is about isolating the view and using data binding to wire up changes to a “view model”, where the changes edit properties, and then the view model takes on the requirements of updating the model.  I’ve written about MVVM in detail, and used it quite a bit, but there are a few annoying aspects:

• Everything is based on mutation.  By definition, the View Model layer is going to be mutable, as edits work via (two way) data binding that set values on the properties.
• There’s a lot of boilerplate involved – every view typically ends up needing a complete class written for it to manage its state and logic.
• It can be difficult to reason about, especially when collections are involved.
• The “plumbing” requirements to keep updates within collections can become onerous quickly.  This tends to lead to inappropriate changes being made to the Model, as evidenced by the common arguments like “it’s just easier if I make this model mutable and implement INotifyPropertyChanged”.  Over time, this can make the application far more complex, introduce bugs, and cause a myriad of other problems.

That being said, MVVM does bring some concrete benefits:

• The View stays very isolated, and can be changed without changing the application logic and code at all.
• The Model can be kept “pure”, which allows for easy reuse of the core code in other platforms (though, in practice, this is often broken – see above).

This year, I’ve decided to go with a completely different approach.

At the beginning of 2016, I started playing with ideas of how to break some of the underlying expectations when building WPF (and other data binding based) applications.  This centered around a couple of ideas - rethinking data binding to eliminate mutation at its core and eliminating the need to create classes to make data binding work.  This has evolved into the Gjallarhorn.Binding project, built on top of Gjallarhorn.

In order to build a UI with Gjallarhorn, instead of making classes to support data binding, I create some simple functions, referred to as a “Component” in Gjallarhorn.Bindable.  A Component is defined as:

BindingSource -> ISignal<'TModel> -> IObservable<'TMessage> list

The BindingSource type is defined in Gjallarhorn.Bindable, and used to map the model to the view, and events from the view back into messages.  The ISignal<‘a> interface is the core type in Gjallarhorn, and can be thought of as an IObservable<‘a> (which it inherits) that always contains a current value.  Gjallarhorn provides a full set of operations for working with signals, including mapping, merging, filtering, conversion to and from observables and other types, and more.  The Component for mapping the Tree to something usable by data binding is defined as:

This function takes the model (the ISignal<Tree>) and binds it directly “to the view” via the name “Tree”.  This effectively creates a one-way “Tree property” the view can data bind into.  I then create a “message source”, which WPF sees as an ICommand.  The Binding.createMessage function returns an IObservable<‘a>. When the command is executed, it will output a Decorate message into the observable stream.

Similarly, I create a Component to manage the Forest type as a whole:

This is slightly different – as the Forest is a sequence, I use BindingCollection.toView to bind the entire collection to the view, saying “for each item in the sequence (a Tree), use the treeComponent function to build out the binding for that element, and aggregate all of the messages from those into a single message stream that’s the original message and the individual tree as a tuple.  I then map this in the output stream into UpdateTree message types, and also create a command to add a new tree, which maps the command parameter into the argument of the Add DU case.

Finally, I build the application plumbing.  The one thing I’m not handling at this point is pruning of the forest – which I want to just run continually.  For Gjallarhorn.Bindable, I need to create three functions for the application – a function to create the initial model (the Forest), an init function that runs one time after all of the contexts have been setup, and an update function for the top level model.  These are passed into the Framework.application function, along with the main component, which builds out the “logical application”:

At this point, I have the underlying logic for the entire application defined – and best of all, it’s defined in a portable class library that’s completely reusable as-is between WPF and other data binding platforms – I could use this same project, without changes, to build out a Xamarin Forms Android app, for example.

The WPF project just references this, pulls in FsXaml, and has two files.  First, I define the XAML for the View:

This looks very similar to the XAML from last year, except that I moved the Tree rendering into its own resource, and simplified the event handling.  I no longer need two converters – only a single converter is required (to go from clicking on the Canvas to a Location for adding a tree) – Gjallarhorn.Bindable takes care of mapping the ICommand to a Decorate message without any work being done in the View, but clicking on the Canvas and mapping to a location requires a converter to be written:

This converter is similar to the one last year – but I’m taking advantage of a newer FsXaml feature that allows us to convert to an option and filter out None results automatically.

Once that’s done, I load the XAML using the FsXaml type provider, and the application entry point becomes nothing but having the WPF specific portion of Gjallarhorn (from the Gjallarhorn.Bindable.Wpf reference) launch the application.  This just requires a single function call – it takes a function to construct an Application (in this case, I’m using the default WPF application), the main Window (from the type provider), and the application from the portable class library:

That’s it – the entire application.  Every line of source code (other than namespace definitions and open statements) is included.  When I run, I get an improved version of what I had last year.  I can click on the window to add trees, and click on a tree to decorate them.  The main improvement is in the pruning behavior – if I add more than 10 trees, I start to see some disappear one at a time every half second, using some randomness that didn’t exist in the previous version.

I’d like to point out some differences here when compared to last year – The model is completely immutable and pure.  The entire application state is defined in one place, and easily managed.  I just need to provide a mechanism to turn it into a signal (to monitor changes) and to update.  Nowhere in this application do I worry about threading or synchronization, even though the pruning is happening in background threads asynchronously.  I don’t create a single “view model” class for data binding, rather just define simple functions that map from my model to binding targets, and route messages out.  The entire application is simple, easy to reason about, and very clean.

In addition, this application is far easier to modify as requirements change.  For fun, I’m going to add some new functionality.  In addition to decorating the tree, I’m going to add the ability to light a tree.

I’ll modify the Model to allow trees to be decorated and lit. This requires changing the Tree record, adding a new Light message, and modifying the update function:

Now I need to add another command to the tree component which generates Light messages:

Finally, I need to tweak the XAML slightly.  It needs two changes – a way to trigger the new command (I’ll use right mouse to light the tree), and the actual rendering of the lights as another path.  First, I put in the right mouse click EventToCommand:

And then I add a new path for the lights (full xaml not shown), and update the instructions:

Now, when I run, I can light and decorate the trees!

This required no major changes to plumbing – I wanted to update how trees work, so a simple addition to the Tree model, and a couple of lines of code, and I’m done.  The entire set of changes required to add lighting is trivial, and can be seen in this GitHub commit.

As always, I’ve put the code on GitHub, so please download, try it out, and enjoy!

And remember to enjoy the rest of the F# content in the 2016 F# Advent Calendar!

Update on Dec 16th: A new “blinking” branch of the repository has been created, showing off submitted improvements, such as making the lights blink on and off!  Definitely worth trying the original and the improved versions.  Thank you Gene Chiaramonte (@waahhoo) and family!

This post will illustrate using a pair of MailboxProcessor instances mixed with FSharp.ViewModule to construct a simple application.  In the spirit of F# Advent, our application will be a small drawing application that allows us to place and decorate Christmas trees.

In order to start, we need a way to represent a collection of trees.  For this application, Iâ€ve created a simple model, comprised of Tree and Forest records, with some functions for manipulating a Forest:

In addition, I have a ForestManager module, which provides a mechanism to use MailboxProcessor to provide updates to a Forest.  Discriminated unions provide the mechanisms for specifying an update and receiving a result.  In our case, an update can be adding a new tree to a forest, or decorating an existing tree within a forest.  As the entire Forest is immutable, either of these would need to create a new Forest.

In order to request updates, as well as update our view, I’m using two MailboxProcessors.  Our view creates a MailboxProcessor<ForestUpdateResult>, which is will use to receive notifications of new Forests.  The ForestManager has a single function which accepts this processor, and creates a secondary one which can be used to post updates.  A single processor would work using PostAndReply, but the advantage of having two is that the model can request updates independently of the view layers, and all user events that require an update just post to a MailboxProcessor, which simplifies the view dramatically.

The manager effectively just delegates the update requests to the Forest functions, and posts to the view’s Mailbox whenever an update needs to occur:

While this is simple, in a more complicated application, the “manager” within the Model layer can very easily add more updates triggered by external sources, which provides one advantage of having separate MailboxProcessors instead of using a single processor via PostAndReply.

Now that we have our Model layer defined, we need a way to interact with this from the View.  This is where FSharp.ViewModule comes into play.  For this application, my view model uses EventViewModelBase from FSharp.ViewModule. This allows us to react to user input as a stream of strongly typed events.

The first thing we’ll need is to create our ViewModel and view Event types, and define a single property and backing field for the Forest we’re viewing.

This allows the current Forest, defaulting to an empty forest, to be bound by our view.  All of the INotifyPropertyChanged plumbing gets handled internally by FSharp.ViewModule’s base classes for us.

Next, we need to create our MailboxProcessors.  First, we need one that we can listen to in order to receive updates to our Forest.  Once that’s created, we can request one to post updates to from the ForestManager module.  Note that I’m capturing the SynchronizationContext and handling it within the agent – in this case, that’s actually unnecessary, but it makes the updates fully threadsafe with WPF if our Model were to post updates from multiple threads, even if we decided to change how we work with the Forest (such as keeping an ObservableCollection for history, which would require synchronization).

The reporter MailBoxProcessor we create listens for updates, and updates our current forest whenever an update occurs.  We can handle different types if we wanted to post status updates to the user (which I’m currently not doing), and easily extend this to other types of updates or errors as needed.

We pass the reporter to the Manager to create a second MailboxProcessor: updateAgent.  This will be then used within our event stream, and allow us to post update requests back to the Model.  Each user event maps to one update request, and, from the ViewModel perspective, requests are completely decoupled from the updates to display back to the user:

Once this is done, all of the logic for our program is complete.  All that’s left is to wire up a user interface.  FsXaml provides some helpers which can be used to convert EventArgs into our TreeEvent discriminated union, so we create two converters, and use them via EventToCommand behaviors to push mouse clicks into our ViewModel.

The key portion is line 12 and 23 – by using our converter, we can map a MouseEventArgs instance when the user clicks into our strongly typed event, and route that directly to our VM.

Once that’s done, if we run, we see:

Clicking in the window should add a tree – and clicking on a tree will “decorate” it:

Once we get more than 10 trees, adding another will prune the forest and remove trees, which illustrates how events separate from the UI automatically populate through to the user interface automatically.

All of the source code is available on GitHub at https://github.com/ReedCopsey/AdventTrees.  Please download, try it out, and enjoy!

And remember to enjoy the rest of the F#-rich goodness that is the 2015 F# Advent!

I fondly remember sitting in a room with a few dedicated F# enthusiasts back in November of 2013. The passion for F# and excitement with seeing its steady growth was addictive. Nobody in the room could avoid being excited as Mathias proposed to make 2014 be “the year of F#.” The community was energized. Little did I realize, at that point, how prophetic that simple statement would become.

This year has been an amazing year for F#. This community astounds me on a regular basis, and this year has surpassed all concepts of expectations I held previously. While I won’t even attempt to list all of the highlights, some of my personal favorite events this year have included:

• Visual F# Tools accepting pull requests and then even releasing an out of band release with community contributions
• Xamarin 3 including “F# Awesomeness” in all downloads of Xamarin Studio
• IntelliFactory releasing WebSharper 3 under an Apache 2.0 license
• The announcement of an open sourced .NET Core
• The community working together to create a new F# logo
• Entire “F# tracks” at many conferences with numerous speakers
• A community driven push towards F# 4.0, with a large list of contributors
• Intense open source contributions in the F# ecosystem – with consistent improvements throughout the year, and some projects getting over 200 commits in a single week!
• New F# User Groups being created around the world, with more speakers, talks, and topics than ever before
• Too many other things to list, including wonderful blog posts, two F# Advent calendars - in English and in Japanese, an active F# chat room, new coding dojos, and more…

I am thankful to everybody in the F# community. Thank you for a wonderful year. It has been my honor and my pleasure to work with many of you. I’ve met wonderful new colleagues, and look forward to meeting many more of you in the upcoming year.

Which brings me to my personal favorite F# event of the year – legally forming the F# Software Foundation. Late in the year, a group of dedicated community members helped move the F# Software Foundation (FSSF) from an informal organization to a legally established entity, and are diligently working to make the FSSF the organization the F# community deserves. I still feel honored to be a part of this endeavor, and am dedicated to helping in any and every way possible moving forward.

Yesterday, we announced the new membership site, where anybody can join the FSSF and become a member. We immediately had people signing up, and we have been receiving very positive feedback on everything being done with FSSF.

I’d like to propose that everybody in the community, whether you’ve been using F# for years or minutes, to join me in a call to action.

Join the F# Software Foundation.

The F# Software Foundation can only ever be as good as its membership. I encourage anybody with an interest in F# to join as a member, and share your ideas for the F# Software Foundation.

• If you’re a dedicated member of the F# community, hopefully your name is already on the member roster. If not, it only takes a few minutes to be listed.
• Are you a Scala developer who is interested to see what’s happening in the newly opened source .NET world? Join our community.
• Are you a C# developer in love with LINQ who might like to learn more functional programming? Join our community and see what F# has to offer.
• Are you a JavaScript developer who’d love to see how type safety via WebSharper or FunScript could change the way you think about programming? Join our community.
• Would you like to work with data from multiple sources, with type safety and IDE integration? Investigate type providers and join our community.
• Everybody is welcome and encouraged to become a member. If you agree with the Mission of the FSSF, join us!

2014 has been an amazing year for F# –

Let’s roll out the end of the year with a shower of new members, and make 2015 even better!

This includes the complete slide deck, and all 4 projects, including:

• FakeService: Simple WCF service to run locally and simulate network service calls.
• AsyncService: Simple WCF service which wraps FakeService to demonstrate converting sync to async
• SimpleWPFExample: Simplest example of converting a method call to async from a synchronous version
• AsyncExamples: Windows Store application demonstrating main concepts, pitfalls, tips, and tricks from the slide deck

The MSDN Multiple Windows, Multiple Threads Sample* showed how to launch a new thread with a WPF Window, and will work in most cases.  The sample code (commented and slightly modified) works out to the following:

// Create a thread
Thread newWindowThread = new Thread(new ThreadStart( () =>
{
    // Create and show the Window
    Window1 tempWindow = new Window1();
    tempWindow.Show();
    // Start the Dispatcher Processing
    System.Windows.Threading.Dispatcher.Run();
}));
// Set the apartment state
newWindowThread.SetApartmentState(ApartmentState.STA);
// Make the thread a background thread
newWindowThread.IsBackground = true;
// Start the thread
newWindowThread.Start();

This sample creates a thread, marks it as single threaded apartment state, and starts the Dispatcher on that thread. That is the minimum requirements to get a Window displaying and handling messages correctly, but, unfortunately, has some serious flaws.

*Note: The referenced sample is no longer available as of 2013. A new Multithreaded Web Browser Sample shows a similar technique and code

The first issue – the created thread will run continuously until the application shuts down, given the code in the sample.  The problem is that the ThreadStart delegate used ends with running the Dispatcher.  However, nothing ever stops the Dispatcher processing.  The thread was created as a Background thread, which prevents it from keeping the application alive, but the Dispatcher will continue to pump dispatcher frames until the application shuts down.

In order to fix this, we need to call Dispatcher.InvokeShutdown after the Window is closed.  This would require modifying the above sample to subscribe to the Windowâ€s Closed event, and, at that point, shutdown the Dispatcher:

// Create a thread
Thread newWindowThread = new Thread(new ThreadStart( () =>
{
    Window1 tempWindow = new Window1();
    // When the window closes, shut down the dispatcher
    tempWindow.Closed += (s,e) => 
       Dispatcher.CurrentDispatcher.BeginInvokeShutdown(DispatcherPriority.Background);

    tempWindow.Show();
    // Start the Dispatcher Processing
    System.Windows.Threading.Dispatcher.Run();
}));
// Setup and start thread as before

This eliminates the first issue.  Now, when the Window is closed, the new threadâ€s Dispatcher will shut itself down, which in turn will cause the thread to complete.

The above code will work correctly for most situations.  However, there is still a potential problem which could arise depending on the content of the Window1 class.  This is particularly nasty, as the code could easily work for most windows, but fail on others.

The problem is, at the point where the Window is constructed, there is no active SynchronizationContext.  This is unlikely to be a problem in most cases, but is an absolute requirement if there is code within the constructor of Window1 which relies on a context being in place.

While this sounds like an edge case, itâ€s fairly common.  For example, if a BackgroundWorker is started within the constructor, or a TaskScheduler is built using TaskScheduler.FromCurrentSynchronizationContext() with the expectation of synchronizing work to the UI thread, an exception will be raised at some point.  Both of these classes rely on the existence of a proper context being installed to SynchronizationContext.Current, which happens automatically, but not until Dispatcher.Run is called.  In the above case, SynchronizationContext.Current will return null during the Windowâ€s construction, which can cause exceptions to occur or unexpected behavior.

Luckily, this is fairly easy to correct.  We need to do three things, in order, prior to creating our Window:

• Create and initialize the Dispatcher for the new thread manually
• Create a synchronization context for the thread which uses the Dispatcher
• Install the synchronization context

Creating the Dispatcher is quite simple – The Dispatcher.CurrentDispatcher property gets the current threadâ€s Dispatcher and “creates a new Dispatcher if one is not already associated with the thread.”  Once we have the correct Dispatcher, we can create a SynchronizationContext which uses the dispatcher by creating a DispatcherSynchronizationContext.  Finally, this synchronization context can be installed as the current threadâ€s context via SynchronizationContext.SetSynchronizationContext.  These three steps can easily be added to the above via a single line of code:

// Create a thread
Thread newWindowThread = new Thread(new ThreadStart( () =>
{
    // Create our context, and install it:
    SynchronizationContext.SetSynchronizationContext(
        new DispatcherSynchronizationContext(
            Dispatcher.CurrentDispatcher));

    Window1 tempWindow = new Window1();
    // When the window closes, shut down the dispatcher
    tempWindow.Closed += (s,e) => 
       Dispatcher.CurrentDispatcher.BeginInvokeShutdown(DispatcherPriority.Background);

    tempWindow.Show();
    // Start the Dispatcher Processing
    System.Windows.Threading.Dispatcher.Run();
}));
// Setup and start thread as before

This now forces the synchronization context to be in place before the Window is created and correctly shuts down the Dispatcher when the window closes.

However, there are quite a few steps.  In my next post, Iâ€ll show how to make this operation more reusable by creating a class with a far simpler API…

• GiveCamp provides real value to organizations that truly need help. 

The Seattle event alone succeeded in helping sixteen non-profit organizations in many different ways.  The projects involved varied dramatically, including website redesigns, SEO, reworking data management workflows, and even game development. 

Many non-profits have a strong need for good, quality technical help.  However, nearly every non-profit organization has an incredibly limited budget.  GiveCamp is a way to really give back, and provide incredibly valuable help to organizations that truly benefit.

My experience has shown many developers to be incredibly generous – this is a chance to dedicate your energy to helping others in a way that really takes advantage of your expertise.  Your time as a developer is incredibly valuable, and this puts something of incredible value directly into the hands of places its needed.

First, and foremost, GiveCamp is about providing technical help to non-profit organizations in need.

• GiveCamp can make you a better developer. 

This is a fantastic opportunity for us, as developers, to work with new people, in a new setting.  The incredibly short time frame (one weekend for a deliverable project) and intense motivation to succeed provides a huge opportunity for learning from peers. 

Iâ€d personally like to thank off the developers with whom I worked – I learned something from each and every one of you.  I hope to see and work with all of you again someday.

• GiveCamp provides an opportunity for you to work outside of your comfort zone.

While itâ€s always nice to be an expert, itâ€s also valuable to work on a project where you have little or no direct experience.  My team focused on a complete reworking of our organizations message and a complete new website redesign and deployment using WordPress. 

While Iâ€d used WordPress for my blog, and had some experience, this is completely unrelated to my professional work.  In fact, nobody on our team normally worked directly with the technologies involved – yet together we managed to succeed in delivering our goals. 

As developers, itâ€s easy to want to stay abreast of new technology surrounding our expertise, but its rare that we get a chance to sit down and work on something practical that is completely outside of our normal realm of work.  Iâ€m a desktop developer by trade, and spent much of the weekend working with CSS and Photoshop.  Many of the projects organizations need donâ€t match perfectly with the skill set in the room – yet all of the software professionals rose to the occasion and delivered practical, usable applications.

• GiveCamp is a short term, known commitment.

While this seems obvious, I think itâ€s an important aspect to remember.  This is a huge part of what makes it successful – you can work, completely focused, on a project, then walk away completely when youâ€re done.  There is no expectation of continued involvement.  While many of the professionals Iâ€ve talked to are willing to contribute some amount of their time beyond the camp, this is not expected.

The freedom this provides is immense.  In addition, the motivation this brings is incredibly valuable.  Every developer in the room was very focused on delivering in time – you have one shot to get it as good as possible, and leave it with the organization in a way that can be maintained by them.  This is a rare experience – and excellent practice at time management for everyone involved.

• GiveCamp provides a great way to meet and network with your peers.

Not only do you get to network with other software professionals in your area – you get to network with amazing people.  Every single person in the room is there to try to help people.  The balance of altruism, intelligence, and expertise in the room is something Iâ€ve never before experienced.

During the presentations of what was accomplished, I felt blessed to participate.  I know many people in the room were incredibly touched by the level of dedication and accomplishment over the weekend.

• GiveCamp is fun.

At the end of the experience, I would have signed up again, even if it was a painful, tedious weekend – merely due to the amazing accomplishments achieved throughout the event.  However, the event is fun. 

Everybody I talked to, the entire weekend, was having a good time.  While there were many faces focused into a near grimace at times (including mine, Iâ€ll admit), this was always in response to a particularly challenging problem or task.  The challenges just added to the overall enjoyment of the weekend – part of why I became a developer in the first place is my love for challenge and puzzles, and a short deadline using unfamiliar technology provided plenty of opportunity for puzzles.  As soon as people would stand up, it was another smile.

If youâ€re a developer, Iâ€d recommend looking at GiveCamp more closely.  Watch for an event in your area.  If there isnâ€t one, consider building a team and organizing an event.  The experience is worth the commitment. 

Typically, loading a pre-.NET 4 mixed mode assembly is handled simply by changing your app.Config file, and including the relevant attribute in the startup element:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
  </startup>
</configuration>

This causes your application to run correctly, and load the older, mixed-mode assembly without issues. For full details on whatâ€s happening here and why, I recommend reading Mark Millerâ€s detailed explanation of this attribute and the reasoning behind it.

Before I show any code, let me say:

• I strongly recommend using the official approach of using app.config to set this policy.

That being said, there are (rare) times when, for one reason or another, changing the application configuration file is less than ideal.

While this is the supported approach to handling this issue, the CLR Hosting API includes a means of setting this programmatically via the ICLRRuntimeInfo interface.  Normally, this is used if youâ€re hosting the CLR in a native application in order to set this, at runtime, prior to loading the assemblies.  However, the F# Samples include a nice trick showing how to load this API and bind this policy, at runtime.  This was required in order to host the Managed DirectX API, which is built against an older version of the CLR.

This is fairly easy to port to C#.  Instead of a direct port, I also added a little addition – by trapping the COM exception received if unable to bind (which will occur if the 2.0 CLR is already bound), I also allow a runtime check of whether this property was setup properly:

public static class RuntimePolicyHelper
{
    public static bool LegacyV2RuntimeEnabledSuccessfully { get; private set; }

    static RuntimePolicyHelper()
    {
        ICLRRuntimeInfo clrRuntimeInfo =
            (ICLRRuntimeInfo)RuntimeEnvironment.GetRuntimeInterfaceAsObject(
                Guid.Empty, 
                typeof(ICLRRuntimeInfo).GUID);
        try
        {
            clrRuntimeInfo.BindAsLegacyV2Runtime();
            LegacyV2RuntimeEnabledSuccessfully = true;
        }
        catch (COMException)
        {
            // This occurs with an HRESULT meaning 
            // "A different runtime was already bound to the legacy CLR version 2 activation policy."
            LegacyV2RuntimeEnabledSuccessfully = false;
        }
    }

    [ComImport]
    [InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
    [Guid("BD39D1D2-BA2F-486A-89B0-B4B0CB466891")]
    private interface ICLRRuntimeInfo
    {
        void xGetVersionString();
        void xGetRuntimeDirectory();
        void xIsLoaded();
        void xIsLoadable();
        void xLoadErrorString();
        void xLoadLibrary();
        void xGetProcAddress();
        void xGetInterface();
        void xSetDefaultStartupFlags();
        void xGetDefaultStartupFlags();

        [MethodImpl(MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime)]
        void BindAsLegacyV2Runtime();
    }
}

Using this, itâ€s possible to not only set this at runtime, but also verify, prior to loading your mixed mode assembly, whether this will succeed.

In my case, this was quite useful – I am working on a library purely for internal use which uses a numerical package that is supplied with both a completely managed as well as a native solver.  The native solver uses a CLR 2 mixed-mode assembly, but is dramatically faster than the pure managed approach.  By checking RuntimePolicyHelper.LegacyV2RuntimeEnabledSuccessfully at runtime, I can decide whether to enable the native solver, and only do so if I successfully bound this policy.

There are some tricks required here – To enable this sort of fallback behavior, you must make these checks in a type that doesnâ€t cause the mixed mode assembly to be loaded.  In my case, this forced me to encapsulate the library I was using entirely in a separate class, perform the check, then pass through the required calls to that class.  Otherwise, the library will load before the hosting process gets enabled, which in turn will fail.

This code will also, of course, try to enable the runtime policy before the first time you use this class – which typically means just before the first time you check the boolean value.  As a result, checking this early on in the application is more likely to allow it to work.

Finally, if youâ€re using a library, this has to be called prior to the 2.0 CLR loading.  This will cause it to fail if you try to use it to enable this policy in a plugin for most third party applications that donâ€t have their app.config setup properly, as they will likely have already loaded the 2.0 runtime.

As an example, take a simple audio player.  The code below shows how this can be used to properly, at runtime, only use the “native” API if this will succeed, and fallback (or raise a nicer exception) if this will fail:

public class AudioPlayer
{
    private IAudioEngine audioEngine;

    public AudioPlayer()
    {
        if (RuntimePolicyHelper.LegacyV2RuntimeEnabledSuccessfully)
        {
            // This will load a CLR 2 mixed mode assembly
            this.audioEngine = new AudioEngineNative();
        }
        else
        {
            this.audioEngine = new AudioEngineManaged();
        }
    }

    public void Play(string filename)
    {
        this.audioEngine.Play(filename);
    }
}

Now – the warning:

This approach works, but I would be very hesitant to use it in public facing production code, especially for anything other than initializing your own application.  While this should work in a library, using it has a very nasty side effect: you change the runtime policy of the executing application in a way that is very hidden and non-obvious.

I mention that this is only a portion of the entire quote, and, as such, I feel that Knuth is being quoted out of context.  Optimization is important.  It is a critical part of every software development effort, and should never be ignored.  A developer who ignores optimization is not a professional.  Every developer should understand optimization – know what to optimize, when to optimize it, and how to think about code in a way that is intelligent and productive from day one.

I want to start by discussing my own, personal motivation here.  I recently wrote about a performance issue I ran across, and was slammed by multiple comments and emails that effectively boiled down to: “Youâ€re an idiot.  Premature optimization is the root of all evil.  This doesnâ€t matter.”  It didnâ€t matter that I discovered this while measuring in a profiler, and that it was a portion of my code base that can take “many hours to complete.”  Even so, multiple people instantly jump to “itâ€s premature – it doesnâ€t matter.”

This is a common thread I see.  For example, StackOverflow has many pages of posts with answers that boil down to (mis)quoting Knuth.  In fact, just about any question relating to a performance related issue gets this quote thrown at it immediately – whether it deserves it or not. 

That being said, I did receive some positive comments and emails as well.  Many people want to understand how to optimize their code, approaches to take, tools and techniques they can use, and any other advice they can discover.

First, lets get back to Knuth – I mentioned before that Knuth is being quoted out of context.  Lets start by looking at the entire quote from his 1974 paper Structured Programming with go to Statements:

“We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.”

Ironically, if you read Knuthâ€s original paper, this statement was made in the middle of a discussion of how Knuth himself had changed how he approaches optimization.  It was never a statement saying “donâ€t optimize”, but rather, “optimizing intelligently provides huge advantages.”  His approach had three benefits: “a) it doesnâ€t take long” … “b) the payoff is real”, c) you can “be less efficient in the other parts of my programs, which therefore are more readable and more easily written and debugged.”

Looking at Knuthâ€s premise here, and reading that section of his paper, really leads to a few observations:

• Optimization is important  “he will be wise to look carefully at the critical code”
• Normally, 3% of your code – three lines out of every 100 you write, are “critical code” and will require some optimization: “we should not pass up our opportunities in that critical 3%”
• Optimization, if done well, should not be time consuming: “it doesnâ€t take long”
• Optimization, if done correctly, provides real benefits: “the payoff is real”

None of this is new information.  People who care about optimization have been discussing this for years – for example, Rico Marianiâ€s Designing For Performance (a fantastic article) discusses many of the same issues very intelligently.

That being said, many developers seem unable or unwilling to consider optimization.  Many others donâ€t seem to know where to start.  As such, Iâ€m going to spend some time writing about optimization – what is it, how should we think about it, and what can we do to improve our own code.

I recently ran across a nasty scenario that illustrated to me how dangerous following any fixed rules for optimization can be…

The rules in C# when optimizing code are very different than C or C++.  Often, theyâ€re exactly backwards.  For example, in C and C++, lifting a variable out of loops in order to avoid memory allocations often can have huge advantages.  If some function within a call graph is allocating memory dynamically, and that gets called in a loop, it can dramatically slow down a routine.

This can be a tricky bottleneck to track down, even with a profiler.  Looking at the memory allocation graph is usually the key for spotting this routine, as itâ€s often “hidden” deep in call graph.  For example, while optimizing some of my scientific routines, I ran into a situation where I had a loop similar to:

for (i=0; i<numberToProcess; ++i)
{
   // Do some work
   ProcessElement(element[i]);
}

This loop was at a fairly high level in the call graph, and often could take many hours to complete, depending on the input data.  As such, any performance optimization we could achieve would be greatly appreciated by our users.

After a fair bit of profiling, I noticed that a couple of function calls down the call graph (inside of ProcessElement), there was some code that effectively was doing:

// Allocate some data required
DataStructure* data = new DataStructure(num);
// Call into a subroutine that passed around and manipulated this data highly
CallSubroutine(data);
// Read and use some values from here
double values = data->Foo;
// Cleanup 
delete data;
// ...
return bar;

Normally, if “DataStructure” was a simple data type, I could just allocate it on the stack.  However, itâ€s constructor, internally, allocated itâ€s own memory using new, so this wouldnâ€t eliminate the problem.  In this case, however, I could change the call signatures to allow the pointer to the data structure to be passed into ProcessElement and through the call graph, allowing the inner routine to reuse the same “data” memory instead of allocating.  At the highest level, my code effectively changed to something like:

DataStructure* data = new DataStructure(numberToProcess);
for (i=0; i<numberToProcess; ++i)
{
   // Do some work
   ProcessElement(element[i], data);
}
delete data;

Granted, this dramatically reduced the maintainability of the code, so it wasnâ€t something I wanted to do unless there was a significant benefit.  In this case, after profiling the new version, I found that it increased the overall performance dramatically – my main test case went from 35 minutes runtime down to 21 minutes.  This was such a significant improvement, I felt it was worth the reduction in maintainability.

In C and C++, itâ€s generally a good idea (for performance) to:

• Reduce the number of memory allocations as much as possible,
• Use fewer, larger memory allocations instead of many smaller ones, and
• Allocate as high up the call stack as possible, and reuse memory

Iâ€ve seen many people try to make similar optimizations in C# code.  For good or bad, this is typically not a good idea.  The garbage collector in .NET completely changes the rules here.

In C#, reallocating memory in a loop is not always a bad idea.  In this scenario, for example, I may have been much better off leaving the original code alone.  The reason for this is the garbage collector.  The GC in .NET is incredibly effective, and leaving the allocation deep inside the call stack has some huge advantages.  First and foremost, it tends to make the code more maintainable – passing around object references tends to couple the methods together more than necessary, and overall increase the complexity of the code.  This is something that should be avoided unless there is a significant reason.  Second, (unlike C and C++) memory allocation of a single object in C# is normally cheap and fast.  Finally, and most critically, there is a large advantage to having short lived objects.  If you lift a variable out of the loop and reuse the memory, its much more likely that object will get promoted to Gen1 (or worse, Gen2).  This can cause expensive compaction operations to be required, and also lead to (at least temporary) memory fragmentation as well as more costly collections later.

As such, Iâ€ve found that itâ€s often (though not always) faster to leave memory allocations where youâ€d naturally place them – deep inside of the call graph, inside of the loops.  This causes the objects to stay very short lived, which in turn increases the efficiency of the garbage collector, and can dramatically improve the overall performance of the routine as a whole.

In C#, I tend to:

• Keep variable declarations in the tightest scope possible
• Declare and allocate objects at usage

While this tends to cause some of the same goals (reducing unnecessary allocations, etc), the goal here is a bit different – itâ€s about keeping the objects rooted for as little time as possible in order to (attempt) to keep them completely in Gen0, or worst case, Gen1.  It also has the huge advantage of keeping the code very maintainable – objects are used and “released” as soon as possible, which keeps the code very clean.  It does, however, often have the side effect of causing more allocations to occur, but keeping the objects rooted for a much shorter time.

Now – nowhere here am I suggesting that these rules are hard, fast rules that are always true.  That being said, my time spent optimizing over the years encourages me to naturally write code that follows the above guidelines, then profile and adjust as necessary.  In my current project, however, I ran across one of those nasty little pitfalls thatâ€s something to keep in mind – interop changes the rules.

In this case, I was dealing with an API that, internally, used some COM objects.  In this case, these COM objects were leading to native allocations (most likely C++) occurring in a loop deep in my call graph.  Even though I was writing nice, clean managed code, the normal managed code rules for performance no longer apply. 

After profiling to find the bottleneck in my code, I realized that my inner loop, a innocuous looking block of C# code, was effectively causing a set of native memory allocations in every iteration.  This required going back to a “native programming” mindset for optimization.  Lifting these variables and reusing them took a 1:10 routine down to 0:20 – again, a very worthwhile improvement.

Overall, the lessons here are:

• Always profile if you suspect a performance problem – donâ€t assume any rule is correct, or any code is efficient just because it looks like it should be
• Remember to check memory allocations when profiling, not just CPU cycles
• Interop scenarios often cause managed code to act very differently than “normal” managed code.
• Native code can be hidden very cleverly inside of managed wrappers

• Compatibility with Visual Studio SP1
• APIs for Windows Phone 7
• Compatibility with non-English installations
• Compatibility with Visual Studio Express Edition
• More efficient Async methods due to a change in the API
• Numerous bug fixes
• New EULA which allows distribution in production environments

Anybody using the Async CTP should consider upgrading to the new version immediately.  For details, visit the Visual Studio Asynchronous Programming page on MSDN.

The ConcurrentDictionary<TKey, TValue> class was added in .NET 4, and provides a thread-safe, lock free collection of key value pairs.  While this is a fantastic replacement for Dictionary<TKey, TValue>, it has a potential flaw when used with values where construction of the value class is expensive.

The typical way this is used is to call a method such as GetOrAdd to fetch or add a value to the dictionary.  It handles all of the thread safety for you, but as a result, if two threads call this simultaneously, two instances of TValue can easily be constructed.

If TValue is very expensive to construct, or worse, has side effects if constructed too often, this is less than desirable.  While you can easily work around this with locking, Stephen Toub provided a very clever alternative – using Lazy<TValue> as the value in the dictionary instead.

This looks like the following.  Instead of calling:

MyValue value = dictionary.GetOrAdd(
                             key, 
                             () => new MyValue(key));

We would instead use a ConcurrentDictionary<TKey, Lazy<TValue>>, and write:

MyValue value = dictionary.GetOrAdd(
                             key, 
                             () => new Lazy<MyValue>(
                                 () => new MyValue(key)))
                          .Value;

This simple change dramatically changes how the operation works.  Now, if two threads call this simultaneously, instead of constructing two MyValue instances, we construct two Lazy<MyValue> instances.

However, the Lazy<T> class is very cheap to construct.  Unlike “MyValue”, we can safely afford to construct this twice and “throw away” one of the instances.

We then call Lazy<T>.Value at the end to fetch our “MyValue” instance.  At this point, GetOrAdd will always return the same instance of Lazy<MyValue>.  Since Lazy<T> doesnâ€t construct the MyValue instance until requested, the actual MyClass instance returned is only constructed once.

Wrapping existing asynchronous code into a Task or Task<T> is, thankfully, fairly straightforward.  There are two main approaches to this.

Code written using the Asynchronous Programming Model (APM) is very easy to convert to using Task<T>.  The TaskFactory class provides the tools to directly convert APM code into a method returning a Task<T>.  This is done via the FromAsync method.  This method takes the BeginOperation and EndOperation methods, as well as any parameters and state objects as arguments, and returns a Task<T> directly.

For example, we could easily convert the WebRequest BeginGetResponse and EndGetResponse methods into a method which returns a Task<WebResponse> via:

Task<WebResponse> task = Task.Factory
                             .FromAsync<WebResponse>(
                                 request.BeginGetResponse,
                                 request.EndGetResponse,
                                 null);

Event-based Asynchronous Pattern (EAP) code can also be wrapped into a Task<T>, though this requires a bit more effort than the one line of code above.  This is handled via the TaskCompletionSource<T> class.  MSDN provides a detailed example of using this to wrap an EAP operation into a method returning Task<T>.  It demonstrates handling cancellation and exception handling as well as the basic operation of the asynchronous method itself.

The basic form of this operation is typically:

Task<YourResult> GetResultAsync()
{
    var tcs = new TaskCompletionSource<YourResult>();
    // Handle the event, and setup the task results...
    this.GetResultCompleted += (o,e) =>
    {
       if (e.Error != null)
            tcs.TrySetException(e.Error);
       else if (e.Cancelled)
            tcs.TrySetCanceled();
       else
            tcs.TrySetResult(e.Result);
    };

    // Call the EAP-based asynchronous method
    this.GetResult();

    // Return the task from the TaskCompletionSource
    return tcs.Task;
}

We can easily use these methods to wrap our own code into a method that returns a Task<T>.  Existing libraries which cannot be edited can be extended via Extension methods.  The CTP uses this technique to add appropriate methods throughout the framework.

The suggested naming for these methods is to define these methods as “Task<YourResult> YourClass.YourOperationAsync(…)”.  However, this naming often conflicts with the default naming of the EAP.  If this is the case, the CTP has standardized on using “Task<YourResult> YourClass.YourOperationTaskAsync(…)”.

Once weâ€ve wrapped all of our existing code into operations that return Task<T>, we can begin investigating how the Async CTP can be used with our own code.

The first asynchronous pattern used in the .NET framework was the Asynchronous Programming Model (APM).  This pattern was based around callbacks.  A method is used to start the operation.  It typically is named as BeginSomeOperation.  This method is passed a callback defined as an AsyncCallback, and returns an object that implements IAsyncResult.  Later, the IAsyncResult is used in a call to a method named EndSomeOperation, which blocks until completion and returns the value normally directly returned from the synchronous version of the operation.  Often, the EndSomeOperation call would be called from the callback function passed, which allows you to write code that never blocks.

While this pattern works perfectly to prevent blocking, it can make quite confusing code, and be difficult to implement.  For example, the sample code provided for FileStreamâ€s BeginRead/EndRead methods is not simple to understand.  In addition, implementing your own asynchronous methods requires creating an entire class just to implement the IAsyncResult.

Given the complexity of the APM, other options have been introduced in later versions of the framework.  The next major pattern introduced was the Event-based Asynchronous Pattern (EAP).  This provides a simpler pattern for asynchronous operations.  It works by providing a method typically named SomeOperationAsync, which signals its completion via an event typically named SomeOperationCompleted.

The EAP provides a simpler model for asynchronous programming.  It is much easier to understand and use, and far simpler to implement.  Instead of requiring a custom class and callbacks, the standard event mechanism in C# is used directly.  For example, the WebClient class uses this extensively.  A method is used, such as DownloadDataAsync, and the results are returned via the DownloadDataCompleted event.

While the EAP is far simpler to understand and use than the APM, it is still not ideal.  By separating your code into method calls and event handlers, the logic of your program gets more complex.  It also typically loses the ability to block until the result is received, which is often useful.  Blocking often requires writing the code to block by hand, which is error prone and adds complexity.

As a result, .NET 4 introduced a third major pattern for asynchronous programming.  The Task<T> class introduced a new, simpler concept for asynchrony.  Task and Task<T> effectively represent an operation that will complete at some point in the future.  This is a perfect model for thinking about asynchronous code, and is the preferred model for all new code going forward.  Task and Task<T> provide all of the advantages of both the APM and the EAP models – you have the ability to block on results (via Task.Wait() or Task<T>.Result), and you can stay completely asynchronous via the use of Task Continuations.  In addition, the Task class provides a new model for task composition and error and cancelation handling.  This is a far superior option to the previous asynchronous patterns.

The Visual Studio Async CTP extends the Task based asynchronous model, allowing it to be used in a much simpler manner.  However, it requires the use of Task and Task<T> for all operations.

This core of the new asynchronous functionality is built upon three key features.  First is the Task functionality in .NET 4, and based on Task and Task<TResult>.  While Task was intended to be the primary means of asynchronous programming with .NET 4, the .NET Framework was still based mainly on the Asynchronous Pattern and the Event-based Asynchronous Pattern.

The .NET Framework added functionality and guidance for wrapping existing APIs into a Task based API, but the framework itself didnâ€t really adopt Task or Task<TResult> in any meaningful way.  The CTP shows that, going forward, this is changing.

One of the three key new features coming in C# is actually a .NET Framework feature.  Nearly every asynchronous API in the .NET Framework has been wrapped into a new, Task-based method calls.  In the CTP, this is done via as external assembly (AsyncCtpLibrary.dll) which uses Extension Methods to wrap the existing APIs.  However, going forward, this will be handled directly within the Framework.  This will have a unifying effect throughout the .NET Framework.  This is the first building block of the new features for asynchronous programming:

Going forward, all asynchronous operations will work via a method that returns Task or Task<TResult>

The second key feature is the new async contextual keyword being added to the language.  The async keyword is used to declare an asynchronous function, which is a method that either returns void, a Task, or a Task<T>.

Inside the asynchronous function, there must be at least one await expression.  This is a new C# keyword (await) that is used to automatically take a series of statements and break it up to potentially use discontinuous evaluation.  This is done by using await on any expression that evaluates to a Task or Task<T>.

For example, suppose we want to download a webpage as a string.  There is a new method added to WebClient: Task<string> WebClient.DownloadStringTaskAsync(Uri).  Since this returns a Task<string> we can use it within an asynchronous function.  Suppose, for example, that we wanted to do something similar to my asynchronous Task example – download a web page asynchronously and check to see if it supports XHTML 1.0, then report this into a TextBox.  This could be done like so:

private async void button1_Click(object sender, RoutedEventArgs e)
{
    string url = "http://reedcopsey.com";
    string content = await new WebClient().DownloadStringTaskAsync(url);
    this.textBox1.Text = string.Format("Page {0} supports XHTML 1.0: {1}",
      url, content.Contains("XHTML 1.0"));
}

Letâ€s walk through whatâ€s happening here, step by step.  By adding the async contextual keyword to the method definition, we are able to use the await keyword on our WebClient.DownloadStringTaskAsync method call.

When the user clicks this button, the new method (Task<string> WebClient.DownloadStringTaskAsync(string)) is called, which returns a Task<string>.  By adding the await keyword, the runtime will call this method that returns Task<string>, and execution will return to the caller at this point.  This means that our UI is not blocked while the webpage is downloaded.  Instead, the UI thread will “await” at this point, and let the WebClient do itâ€s thing asynchronously.

When the WebClient finishes downloading the string, the user interfaceâ€s synchronization context will automatically be used to “pick up” where it left off, and the Task<string> returned from DownloadStringTaskAsync is automatically unwrapped and set into the content variable.  At this point, we can use that and set our text box content.

There are a couple of key points here:

Asynchronous functions are declared with the async keyword, and contain one or more await expressions

In addition to the obvious benefits of shorter, simpler code – there are some subtle but tremendous benefits in this approach.  When the execution of this asynchronous function continues after the first await statement, the initial synchronization context is used to continue the execution of this function.  That means that we donâ€t have to explicitly marshal the call that sets textbox1.Text back to the UI thread – itâ€s handled automatically by the language and framework!  Exception handling around asynchronous method calls also just works.

Iâ€d recommend every C# developer take a look at the documentation on the new Asynchronous Programming for C# and Visual Basic page, download the Visual Studio Async CTP, and try it out.

There is a method in the TaskFactory class which can be used to adapt the existing APIs to the new Task class: TaskFactory.FromAsync.  This method provides a way to convert from the BeginOperation/EndOperation method pair syntax common through .NET Framework directly to a Task<T> containing the results of the operation in the taskâ€s Result parameter.

While this method does exist, it unfortunately comes at a cost – the method overloads are far from simple to decipher, and the resulting code is not always as easily understood as newer code based directly on the Task class.  For example, a single call to handle WebRequest.BeginGetResponse/EndGetReponse, one of the easiest “pairs” of methods to use, looks like the following:

var task = Task.Factory.FromAsync<WebResponse>(
                            request.BeginGetResponse,
                            request.EndGetResponse,
                            null);

The compiler is unfortunately unable to infer the correct type, and, as a result, the WebReponse must be explicitly mentioned in the method call.  As a result, I typically recommend wrapping this into an extension method to ease use.  For example, I would place the above in an extension method like:

public static class WebRequestExtensions
{
    public static Task<WebResponse> GetReponseAsync(this WebRequest request)
    {
        return Task.Factory.FromAsync<WebResponse>(
                        request.BeginGetResponse,
                        request.EndGetResponse,
                        null);
    }
}

This dramatically simplifies usage.  For example, if we wanted to asynchronously check to see if this blog supported XHTML 1.0, and report that in a text box to the user, we could do:

var webRequest = WebRequest.Create("http://www.reedcopsey.com");
webRequest.GetReponseAsync().ContinueWith(t =>
    {
        using (var sr = new StreamReader(t.Result.GetResponseStream()))
        {
            string str = sr.ReadLine();;
            this.textBox1.Text = string.Format("Page at {0} supports XHTML 1.0: {1}", 
                t.Result.ResponseUri, 
                str.Contains("XHTML 1.0"));
        }
    }, TaskScheduler.FromCurrentSynchronizationContext());

By using a continuation with a TaskScheduler based on the current synchronization context, we can keep this request asynchronous, check based on the first line of the response string, and report the results back on our UI directly.

In addition to standard Task continuations , the Task class provides some options for filtering continuations automatically.  This is handled via the TaskContinationOptions enumeration, which provides hints to the TaskScheduler that it should only continue based on the operation of the antecedent task.

This is especially useful when dealing with exceptions.  For example, we can extend the sample from our earlier continuation discussion to include support for handling exceptions thrown by the Factorize method:

// Get a copy of the UI-thread task scheduler up front to use later
var uiScheduler = TaskScheduler.FromCurrentSynchronizationContext();

// Start our task
var factorize = Task.Factory.StartNew(
    () =>
        {
            int primeFactor1 = 0;
            int primeFactor2 = 0;
            bool result = Factorize(10298312, ref primeFactor1, ref primeFactor2);
            return new {
                           Result = result,
                           Factor1 = primeFactor1,
                           Factor2 = primeFactor2
                       };
        });

// When we succeed, report the results to the UI
factorize.ContinueWith(task => textBox1.Text = string.Format("{0}/{1}  [Succeeded {2}]",
                                 task.Result.Factor1,
                                 task.Result.Factor2,
                                 task.Result.Result),
                        CancellationToken.None,
                        TaskContinuationOptions.NotOnFaulted,
                        uiScheduler);

// When we have an exception, report it
factorize.ContinueWith(task => 
                             textBox1.Text = string.Format("Error: {0}", task.Exception.Message),
                        CancellationToken.None,
                        TaskContinuationOptions.OnlyOnFaulted,
                        uiScheduler);

The above code works by using a combination of features.  First, we schedule our task, the same way as in the previous example.  However, in this case, we use a different overload of Task.ContinueWith which allows us to specify both a specific TaskScheduler (in order to have your continuation run on the UIâ€s synchronization context) as well as a TaskContinuationOption. 

In the first continuation, we tell the continuation that we only want it to run when there was not an exception by specifying TaskContinuationOptions.NotOnFaulted.  When our factorize task completes successfully, this continuation will automatically run on the UI thread, and provide the appropriate feedback.

However, if the factorize task has an exception – for example, if the Factorize method throws an exception due to an improper input value, the second continuation will run.  This occurs due to the specification of TaskContinuationOptions.OnlyOnFaulted in the options.  In this case, weâ€ll report the error received to the user.

We can use TaskContinuationOptions to filter our continuations by whether or not an exception occurred and whether or not a task was cancelled.  This allows us to handle many situations, and is especially useful when trying to maintain a valid application state without ever blocking the user interface.  The same concepts can be extended even further, and allow you to chain together many tasks based on the success of the previous ones.  Continuations can even be used to create a state machine with full error handling, all without blocking the user interface thread.

Task continuations provide a clean syntax, and a very simple, elegant means of synchronizing asynchronous method results with the user interface.  In addition, continuations provide a very simple, elegant means of working with collections of tasks.

Prior to .NET 4, working with multiple related asynchronous method calls was very tricky.  If, for example, we wanted to run two asynchronous operations, followed by a single method call which we wanted to run when the first two methods completed, weâ€d have to program all of the handling ourselves.  We would likely need to take some approach such as using a shared callback which synchronized against a common variable, or using a WaitHandle shared within the callbacks to allow one to wait for the second.  Although this could be accomplished easily enough, it requires manually placing this handling into every algorithm which requires this form of blocking.  This is error prone, difficult, and can easily lead to subtle bugs.

Similar to how the Task class static methods providing a way to block until multiple tasks have completed, TaskFactory contains static methods which allow a continuation to be scheduled upon the completion of multiple tasks: TaskFactory.ContinueWhenAll.

This allows you to easily specify a single delegate to run when a collection of tasks has completed.  For example, suppose we have a class which fetches data from the network.  This can be a long running operation, and potentially fail in certain situations, such as a server being down.  As a result, we have three separate servers which we will “query” for our information.  Now, suppose we want to grab data from all three servers, and verify that the results are the same from all three.

With traditional asynchronous programming in .NET, this would require using three separate callbacks, and managing the synchronization between the various operations ourselves.  The Task and TaskFactory classes simplify this for us, allowing us to write:

var server1 = Task.Factory.StartNew( 
                 () => networkClass.GetResults(firstServer) );
var server2 = Task.Factory.StartNew( 
                 () => networkClass.GetResults(secondServer) );
var server3 = Task.Factory.StartNew( 
                 () => networkClass.GetResults(thirdServer) );

var result = Task.Factory.ContinueWhenAll( new[] {server1, server2, server3 },
                 (tasks) => 
                 {
                       // Propogate exceptions (see below)
                       Task.WaitAll(tasks);

                       return this.CompareTaskResults(
                               tasks[0].Result,
                               tasks[1].Result,
                               tasks[2].Result);
                  });

This is clean, simple, and elegant.  The one complication is the Task.WaitAll(tasks); statement.

Although the continuation will not complete until all three tasks (server1, server2, and server3) have completed, there is a potential snag.  If the networkClass.GetResults method fails, and raises an exception, we want to make sure to handle it cleanly.  By using Task.WaitAll, any exceptions raised within any of our original tasks will get wrapped into a single AggregateException by the WaitAll method, providing us a simplified means of handling the exceptions.  If we wait on the continuation, we can trap this AggregateException, and handle it cleanly.  Without this line, itâ€s possible that an exception could remain uncaught and unhandled by a task, which later might trigger a nasty UnobservedTaskException.  This would happen any time two of our original tasks failed.

Just as we can schedule a continuation to occur when an entire collection of tasks has completed, we can just as easily setup a continuation to run when any single task within a collection completes.  If, for example, we didnâ€t need to compare the results of all three network locations, but only use one, we could still schedule three tasks.  We could then have our completion logic work on the first task which completed, and ignore the others.  This is done via TaskFactory.ContinueWhenAny:

var server1 = Task.Factory.StartNew( 
                 () => networkClass.GetResults(firstServer) );
var server2 = Task.Factory.StartNew( 
                 () => networkClass.GetResults(secondServer) );
var server3 = Task.Factory.StartNew( 
                 () => networkClass.GetResults(thirdServer) );

var result = Task.Factory.ContinueWhenAny( new[] {server1, server2, server3 },
                 (firstTask) => 
                 {
                       return this.ProcessTaskResult(firstTask.Result);
                  });

Here, instead of working with all three tasks, weâ€re just using the first task which finishes.  This is very useful, as it allows us to easily work with results of multiple operations, and “throw away” the others.  However, you must take care when using ContinueWhenAny to properly handle exceptions.  At some point, you should always wait on each task (or use the Task.Result property) in order to propogate any exceptions raised from within the task.  Failing to do so can lead to an UnobservedTaskException.

Asynchronous programming methods typically required callback functions.  For example, MSDNâ€s Asynchronous Delegates Programming Sample shows a class that factorizes a number.  The original method in the example has the following signature:

public static bool Factorize(int number, ref int primefactor1, ref int primefactor2)
{
 //...

However, calling this is quite “tricky”, even if we modernize the sample to use lambda expressions via C# 3.0. 

Normally, we could call this method like so:

int primeFactor1 = 0;
int primeFactor2 = 0;

bool answer = Factorize(10298312, ref primeFactor1, ref primeFactor2);
Console.WriteLine("{0}/{1}  [Succeeded {2}]", primeFactor1, primeFactor2, answer);

If we want to make this operation run in the background, and report to the console via a callback, things get tricker.  First, we need a delegate definition:

public delegate bool AsyncFactorCaller(
     int number,
     ref int primefactor1,
     ref int primefactor2);

Then we need to use BeginInvoke to run this method asynchronously:

int primeFactor1 = 0;
int primeFactor2 = 0;

AsyncFactorCaller caller  = new AsyncFactorCaller(Factorize);
caller.BeginInvoke(10298312, ref primeFactor1, ref primeFactor2,
   result =>
       {
           int factor1 = 0;
           int factor2 = 0;
           bool answer = caller.EndInvoke(ref factor1, ref factor2, result);
           Console.WriteLine("{0}/{1}  [Succeeded {2}]", factor1, factor2, answer);
       }, null);

This works, but is quite difficult to understand from a conceptual standpoint.  To combat this, the framework added the Event-based Asynchronous Pattern, but it isnâ€t much easier to understand or author.

Using .NET 4â€s new Task<T> class and a continuation, we can dramatically simplify the implementation of the above code, as well as make it much more understandable.  We do this via the Task.ContinueWith method.  This method will schedule a new Task upon completion of the original task, and provide the original Task (including its Result if itâ€s a Task<T>) as an argument.  Using Task, we can eliminate the delegate, and rewrite this code like so:

var background = Task.Factory.StartNew(
    () =>
        {
            int primeFactor1 = 0;
            int primeFactor2 = 0;
            bool result = Factorize(10298312, ref primeFactor1, ref primeFactor2);
            return new {
                           Result = result,
                           Factor1 = primeFactor1,
                           Factor2 = primeFactor2
                       };
        });
background.ContinueWith(task => Console.WriteLine("{0}/{1}  [Succeeded {2}]",
                                 task.Result.Factor1,
                                 task.Result.Factor2,
                                 task.Result.Result));

This is much simpler to understand, in my opinion.  Here, weâ€re explicitly asking to start a new task, then continue the task with a resulting task.  In our case, our method used ref parameters (this was from the MSDN Sample), so there is a little bit of extra boiler plate involved, but the code is at least easy to understand.

That being said, this isnâ€t dramatically shorter when compared with our C# 3 port of the MSDN code above.  However, if we were to extend our requirements a bit, we can start to see more advantages to the Task based approach.  For example, supposed we need to report the results in a user interface control instead of reporting it to the Console.  This would be a common operation, but now, we have to think about marshaling our calls back to the user interface.  This is probably going to require calling Control.Invoke or Dispatcher.Invoke within our callback, forcing us to specify a delegate within the delegate.  The maintainability and ease of understanding drops.  However, just as a standard Task can be created with a TaskScheduler that uses the UI synchronization context, so too can we continue a task with a specific context.  There are Task.ContinueWith method overloads which allow you to provide a TaskScheduler.  This means you can schedule the continuation to run on the UI thread, by simply doing:

Task.Factory.StartNew(
    () =>
        {
            int primeFactor1 = 0;
            int primeFactor2 = 0;
            bool result = Factorize(10298312, ref primeFactor1, ref primeFactor2);
            return new {
                           Result = result,
                           Factor1 = primeFactor1,
                           Factor2 = primeFactor2
                       };
        }).ContinueWith(task => textBox1.Text = string.Format("{0}/{1}  [Succeeded {2}]",
                                 task.Result.Factor1,
                                 task.Result.Factor2,
                                 task.Result.Result), 
                        TaskScheduler.FromCurrentSynchronizationContext());

This is far more understandable than the alternative.  By using Task.ContinueWith in conjunction with TaskScheduler.FromCurrentSynchronizationContext(), we get a simple way to push any work onto a background thread, and update the user interface on the proper UI thread.  This technique works with Windows Presentation Foundation as well as Windows Forms, with no change in methodology.

While similar to the WindowCloseBehavior code I posted on the Expression Code Gallery, Nishant Sivakumarâ€s version works in WPF without taking a dependency on the Expression Blend SDK.

I highly recommend reading this article: Handling a Windowâ€s Closed and Closing Events in the View-Model.  It is a very nice alternative approach to this common problem in MVVM.

I feel honored and proud to receive this award, and hope that I can continue to be a valuable member of the community in the future.  Thank you to everyone who nominated me!

In order to simplify this process, and make Tasks simple to use in simple cases, without sacrificing their power and flexibility, the Task Parallel Library added a new class: TaskFactory.

The TaskFactory class is intended to “Provide support for creating and scheduling Task objects.”  Its entire purpose is to simplify development when working with Task instances.  The Task class provides access to the default TaskFactory via the Task.Factory static property.  By default, TaskFactory uses the default TaskScheduler to schedule tasks on a ThreadPool thread.  By using Task.Factory, we can automatically create and start a task in a single “fire and forget” manner, similar to how we did with ThreadPool.QueueUserWorkItem:

Task.Factory.StartNew(() => this.ExecuteBackgroundWork(myData) );

This provides us with the same level of simplicity we had with ThreadPool.QueueUserWorkItem, but even more power.  For example, we can now easily wait on the task:

// Start our task on a background thread
var task = Task.Factory.StartNew(() => this.ExecuteBackgroundWork(myData) );

// Do other work on the main thread, 
// while the task above executes in the background
this.ExecuteWorkSynchronously();

// Wait for the background task to finish
task.Wait();

TaskFactory simplifies creation and startup of simple background tasks dramatically.

In addition to using the default TaskFactory, itâ€s often useful to construct a custom TaskFactory.  The TaskFactory class includes an entire set of constructors which allow you to specify the default configuration for every Task instance created by that factory. 

This is particularly useful when using a custom TaskScheduler.  For example, look at the sample code for starting a task on the UI thread in Part 15:

// Given the following, constructed on the UI thread
// TaskScheduler uiScheduler = TaskScheduler.FromCurrentSynchronizationContext();

// When inside a background task, we can do
string status = GetUpdatedStatus();

(new Task(() =>
    {
        statusLabel.Text = status;
    }))
.Start(uiScheduler);

This is actually quite a bit more complicated than necessary.  When we create the uiScheduler instance, we can use that to construct a TaskFactory that will automatically schedule tasks on the UI thread.  To do that, weâ€d create the following on our main thread, prior to constructing our background tasks:

// Construct a task scheduler from the current SynchronizationContext (UI thread)
var uiScheduler = TaskScheduler.FromCurrentSynchronizationContext();
// Construct a new TaskFactory using our UI scheduler
var uiTaskFactory = new TaskFactory(uiScheduler);

If we do this, when weâ€re on a background thread, we can use this new TaskFactory to marshal a Task back onto the UI thread.  Our previous code simplifies to:

// When inside a background task, we can do
string status = GetUpdatedStatus();

// Update our UI
uiTaskFactory.StartNew( () => statusLabel.Text = status);

Notice how much simpler this becomes!  By taking advantage of the convenience provided by a custom TaskFactory, we can now marshal to set data on the UI thread in a single, clear line of code!