#I @"C:\winnt\Microsoft.NET\Framework\v2.0.50727\"
#r @"Microsoft.Build.Tasks.dll"
#r @"Microsoft.Build.Utilities.dll"
#r @"Microsoft.Build.Framework.dll"
#r @"Microsoft.Build.Engine.dll"
 
open System
open Microsoft.Build.Framework
open Microsoft.Build.Utilities
open Microsoft.Build.Tasks
 
do
    let t = 
        ResolveAssemblyReference(Silent = true,
            Assemblies = [| upcast TaskItem( ItemSpec="class1" ) |],
            AllowedAssemblyExtensions = [|".dll"|],
            AppConfigFile = "c:\\dev\\myapp\\myapp.exe.config",
            SearchPaths = [|"{GAC}"|]
            )
    match t.Execute() with
    | true  -> printf "%A\n" t.ResolvedFiles
    | false -> printf "Task failed"

The output is:

[|C:\WINNT\assembly\GAC_MSIL\class1\1.1.8.0__120bce90f68b861a\class1.dll|]

The code makes good use of F#’s named constructor arguments, which map to property setters on the object we’ve just created. We can also create the arrays of TaskItems and strings fairly easily, although an explicit upcast is required in order to obtain the ITaskItem (F# doesn’t upcast implicitly like many object oriented languages).

I’ve just discovered that Jomo Fisher wrote about exactly the same thing back in May 2008! He mentions using an object expression in order to provide an implementation of IBuildEngine, which I’m getting away with by setting the Silent property on the ResolveAssemblyReference task, meaning that it never attempts to obtain the logging context from the build engine.

Another gotcha here is the fact that versions of various interfaces including IBuildEngine and ITaskItem exist in both the 2.0.0.0 and 3.5.0.0 versions of the Microsoft.Build.Framework assembly. Be careful that you reference the correct version for the task that you’re calling. Normally it will be the 2.0 versions, in which case you’ll need to use explicit file references in your script, adding the directory to the library include path:

#I @"C:\winnt\Microsoft.NET\Framework\v2.0.50727\"
#r @"Microsoft.Build.Framework.dll"

Rather than partially qualified assembly references:

#r @"Microsoft.Build.Framework"

As the latter will resolve to the latest installed version of the assembly, 3.5, which is not what you want. Look out for errors like:

System.InvalidCastException: Unable to cast object of type ‘Microsoft.Build.Utilities.TaskItem’ to type ‘Microsoft.Build.Framework.ITaskItem’.

Alternatives

The Tools|Options MSBuild verbosity setting

I’m making use of a few F#/.NET idioms to make the process easier. For instance, sequences (.NET’s IEnumerable) are used as the source of uniformly distributed random numbers. Also, to verify that the resulting numbers are actually normally distributed, we can easily use existing WPF/silverlight controls to visualise the values direct from within Visual Studio, in a manner similar to this previous post – but without having to write the plotting code ourselves.

Implementation

So firstly, we create the random number stream:

let rr = System.Random(System.DateTime.Now.Minute)
let rands = seq { while true do yield rr.NextDouble() }

As you can see rands is an infinite sequence. As such, you should be wary of the “eager” functions from the Seq module that attempt to consume the entire sequence at once, they’ll obviously cause a problem here. Also notice that I’ve picked a somewhat dubious seed for the random number generator, as this is only for demonstration purposes.

In order to obtain normally distributed random numbers I’m using the Box-Muller transform. I started off with an implementation transcribed from VBA (from Wilmott et al) – yes, yes, I know – but of course this used mutable references. Not nice. So I reworked it a little to use Seq.pick, which takes items from the sequence while a predicate returns None:

let boxMuller _ =
    let (x,dist) = 
        rands
        |> Seq.pick (fun x ->
            let x = 2.0 * x - 1.0
            let y = 2.0 * ((Seq.take 1 rands) |> Seq.hd) - 1.0
            match (x * x + y * y) with
                | dist when dist < 1.0 -> Some (x,dist)
                | dist -> None
            ) 
    x * Math.Sqrt(-2.0 * Math.Log(dist) / dist)

It’s not particularly efficient as we’re consuming two uniform numbers to generate one normal one – hence the additional Seq.take within the pick. Of course we could change the function to return the 2 generated numbers as an extra element in the tuple.

Next, let’s generate some numbers, and get them in a suitable form to display:

let makeData _ =
    Seq.init 100000 boxMuller
    |> Seq.countBy (fun d -> 
        let d = decimal d
        Math.Round(d, 1))
    |> Seq.sortBy fst

We initialise a sequence with an arbitrary amount of numbers (100000, enough to get a good distribution, hopefully), then use Seq.countBy to do a naive grouping that allows us to see how the numbers are distributed, i.e. counting how many numbers fit in each 0.10 bucket. We then sort the output by bucket.

Visualisation

Now we can display what we’ve got. We can create a simple WPF object-model using imperative code, including the very useful chart control from the WpfToolkit. The chart control enables us to add a series and set our seq<decimal * float> directly as the series ItemsSource, which is the standard way to specify the items for a collection control. If you specify the tuple Item1 and Item2 properties for the bindings, WPF will be able to access the data from each element, and that’s all you need.

    let series = 
        ColumnSeries(
            IndependentValueBinding = Data.Binding("Item1"),
            DependentValueBinding = Data.Binding("Item2"),
            ItemsSource = makeData ())
    let chart = Chart()
    chart.Series.Add series
    Window(
        Name="Plot",
        Title="Normally distributed random numbers",
        Width=900.0,
        Height=700.0,
        Content=chart,
        Visibility=Visibility.Visible)

Here’s the resulting output:
As I’ve mentioned before, this is a fantastically immediate way of doing numerical development in Visual Studio. You can enter all of this code directly into F# interactive within VS, iterate, and quickly see the effect that your changes have. It’s just as interactive as using the graph features in Excel, and the resulting code is much more easily reusable.

XD5RRV3XDNHN

But one of the things I couldn’t get over from that article is the verbosity. I’ve just got too used to the succintness of F#. I know this is only example code, so it’s intended to demonstrate usage, but the whole point of lambdas is to reduce boilerplate and make the intent of your code more obvious. So, let’s compare the C++0x implementation with the F# version.

Here’s the C++ version, with the comments removed (including the “increment the counter” comment from the original article… Oh, please):

#include <algorithm>
#include <iostream>
#include <vector>
using namespace std;
 
int main()
{
   vector<int> v;
   for (int i = 0; i < 10; ++i)
   {
      v.push_back(i);
   }
 
   int evenCount = 0;
   for_each(v.begin(), v.end(), [&evenCount] (int n) {
      cout << n;
 
      if (n % 2 == 0)
      {
         cout << " is even " << endl;
 
         evenCount++;
      }
      else
      {
         cout << " is odd " << endl;
      }
   });
 
   cout << "There are " << evenCount << " even numbers in the vector." << endl;
}

As well as the verbosity, notice the weird syntax used to capture the evenCount variable.

Without further ado, here’s an F# version – not a definitive one necessarily – that returns the value rather than doing nasty side-effecting IO by printing it out to the screen:

seq { 0..9 } |> Seq.filter (fun e -> e % 2 = 0) |> Seq.length

If you want to make it a bit more like the original code, you can add back the printfs, and lay it out a bit more logically:

let count =
    seq { 0..9 }
    |> Seq.fold (fun count e ->
        match e % 2 with
        | 0 -> printf "%d is even\n" e; count + 1
        | _ -> printf "%d is odd\n" e; count) 0
printf "There are %d even numbers" count

I guess the comparison isn’t really a fair one. The fundamental difference between C++ and F# lambdas is that they’re an afterthought in C++. In F# they’re a core, fundamental part of the language, and have been from day one. Functions are created, passed and bound as a matter of course.

The C++ heritage becomes obvious when you look at the finer points of its lambda syntax. For instance, having to specify whether to capture variables by reference or by value, in the “capture clause” or lambda-introducer. This is the type of distinction that both .NET programmers and functional programmers are not used to having to make.

Other nice F# features

Although not directly related to lambdas, there are some other F# language features that help make code more concise and understandable:

1. Sequence expressions

   F# has an extremely terse syntax for generating and manipulating sequences – collections that implement IEnumerable. This means you can easily generate collections and iterate over them, without the potential for off-by-one errors, the scourge of for

2. Fewer brackets

   In F#, whitespace is significant. It takes some time to get used to, but it ultimately results in cleaner code. It's been interesting to see the use of #light gradually become more and more standard as F# has neared an official release. Now it's implicit in all code. Try it, you'll like it.

3. Type-safe printf

   For some reason I always preferred the C style printf string formatting to C++s cout stream based version. There's something more readable about printf, but it suffers from a terrible lack of compile time type safety. This can be disastrous if, for instance, you happen to wrongly type the insert in an error message or other code path that's rarely hit. The one time you need it, the error handling itself generates an error! Ouch.

   
   Luckily, F# combines the best of both worlds with a compile-time type-safe printf! At first glance this can seem like some kind of magic to C++ developers (well, it did for me).

Now that F# is officially "out there" and available as a first class citizen in Visual Studio 2010, you should really take a look. I'm increasingly convinced that the cost of using C++, not necessarily the raw, low-level cost, but the business costs involved with writing performant, maintainable, manageable code in C++, is getting too much to bear. But that's probably the basis for another post.

I had a look at the text of the first exception, and from that it was obvious:


Unable to cast COM object of type 'System.__ComObject' to interface type 'IWhatever'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{CAD939D0-5E5D-11D7-AA0B-0002B33FE9DX}' failed due to the following error: Bad variable type. (Exception from HRESULT: 0x80020008 (DISP_E_BADVARTYPE)).


The message contains curly brackets around the IID, and they’re being intrepreted as insertion points by a call to String.Format!

Workaround

So that explained why it only happens in debugger runs; as this post helpfully points out the WPF databinding is enabled by default in that case. To workaround it, you can disable logging programmatically or using the App.config file to only display Critical output. So if your app is named foo.exe, create a file foo.exe.config that contains:

<configuration>

  <system.diagnostics>

    <sources>

      <source name="System.Windows.Data" switchName="SourceSwitch"/>

    </sources>

    <switches>

      <add name="SourceSwitch" value="Critical" />

    </switches>

  </system.diagnostics>

</configuration>

Fix…?

Hopefully there’ll be a fix for this at some point soon, as disabling the logging is a pretty large hammer to crack this small nut.

I remembered seeing a post on that Windows SDK blog that I’d come across relating to a similar issue with the XAML editor (I’ve been doing some work with WPF recently, more on that in a later post) so thought I’d try the steps they recommend, in short, re-registering TextMgrP.dll:

regsvr32 "%CommonProgramFiles%\Microsoft Shared\MSEnv\TextMgrP.dll"

…and all my problems went away. Hope you find this useful.

which causes “error FS0072: Lookup on object of indeterminate type based on information prior to this program point”, to the correct:

(These are obviously simplistic examples!)

So I broke out the Visual Studio macro editor for the first time in a while, and put together something to toggle brackets around the currently selected text. It’s naive, but, combined with Shift+Alt+Left Arrow to select the previous word, it’s effective:

Copy this text into a module within your macro project, and assign a suitable keystroke using Tools|Customize|Keyboard.

• Copy as HTML

Fantastic little tool that lets you copy formatted text from the VS editor as HTML fragments. You can’t beat syntax highlighting to ease code readability, and this plug-in is great for adding code to blog entries, etc. Written by Colin Coller and available from http://www.jtleigh.com/CopySourceAsHtml.

• VC++ Code Snippets

C++ has missed out on a few of the productivity boosters available for the managed languages in VS2005; one of the most annoying ones is code snippets – mainly because it’s omission seems so arbitrary, it’s not as if it needs reflection or some other CLR specific features. Anyway, it turns out that it is available, but as part of the “PowerToys” package, available from http://msdn2.microsoft.com/en-us/vstudio/bb190754.aspx. As well as being good for day-to-day productivity, code snippets are also a really powerful demo tool, allowing you to give the appearance that you’re writing code “live” when it’s really just glorified copy and pasting.

• XPathMania

I do quite a lot of work with XML, and this little utility proves very useful. I used to use XMLSpy, but it was really too overblown when all I wanted to do was use it’s ability to quickly run an XPath query and see what it returns. This add-in allows me to do that directly in Visual Studio… lovely! It was put together by Don Demsak, and is available from http://donxml.com/allthingstechie/archive/2006/07/07/2792.aspx.

Anyway, I’ve found a way to improve matters slightly. It turns out you can use the symbol server DLL – symsrv.dll – from the most recent version of WinDbg (6.6.3.5 at the last check) to replace the version that ships with Visual Studio 2005.

One of the additional features that the WinDbg version offers in the exclusions list. You can use this to avoid loading symbols for anything other than the DLL under test. Simply copy the DLL into C:\Program Files\Microsoft Visual Studio 8\Common7\IDE and create a symsrv.ini file with the following contents:

[exclusions]
*.*

This should make your symbol loading fly… yet it still loads the symbols required to debug as normal. Magic!