Cook Computing

I've written some Silverlight value converters recently and I thought it would be useful to implement a base class to make this task easier, also adding some type checking at runtime. This would enable a boolean to Visibility converter to be implemented like this:

public class BooleanToVisibilityConverter 
  : BaseValueConverter<bool, Visibility>
{
  protected override Visibility Convert(bool value, 
    CultureInfo culture)
  {
    return value ? Visibility.Visible : Visibility.Collapsed;
  }
}

The two generic parameters for BaseValueConverter are the type of the value to be converted and the target type. For case where a parameter is used a different base class is used, also called BaseValueConverter, which takes an extra generic parameter specifying the type of the parameter. For example, you may want the Visibility to be based on the inverse of the boolean value, and so the class can be implemented with an extra string generic parameter to specify that the inverse should be used:

public class BooleanToVisibilityConverter 
  : BaseValueConverter<bool, Visibility, String>
{
  protected override Visibility Convert(bool value, 
    string parameter, CultureInfo culture)
  {
    if (parameter != null && parameter == "!")
          value = !value;
    return value ? Visibility.Visible : Visibility.Collapsed;
  }
}

As usual, the CLR namespace needs to be defined, for example if the class is in a namespace called Converters:

  xmlns:c="clr-namespace:Converters" 

And the converter class specified as a resource:

  <UserControl.Resources>
    <c:BooleanToVisibilityConverter 
      x:Key="BooleanToVisibilityConverter"/>
  </UserControl.Resources>

Finally, the converter resource is used in a binding. In this example TextNotVisible is a boolean value in the control's DataContext and the parameter is used to indicate that whenTextNotVisible is true, the converter should return Visibility.Visible:

    <TextBlock Text="Hello World" Margin="20" Name="Txt"
      Visibility="{Binding TextNotVisible, 
        Converter={StaticResource BooleanToVisibilityConverter}, 
        ConverterParameter=!}"

This is the implementation of BaseValueConverter:

public abstract class BaseValueConverter<V, T, P> 
  : IValueConverter
{
  public object Convert(object value, Type targetType,
    object parameter, CultureInfo culture)
  {
    if (value.GetType() != typeof(V))
      throw new ArgumentException(GetType().Name
        + ".Convert: value type not " + typeof(V).Name);
    if (targetType != typeof(T))
      throw new ArgumentException(GetType().Name
        + ".Convert: target type not " + typeof(T).Name);
    return Convert((V)value, (P)parameter, culture);
  }

  public object ConvertBack(object value, Type targetType,
    object parameter, CultureInfo culture)
  {
    if (value.GetType() != typeof(V))
      throw new ArgumentException(GetType().Name
        + ".ConvertBack: value type not " + typeof(V).Name);
    if (targetType != typeof(T))
      throw new ArgumentException(GetType().Name
        + ".ConvertBack: target type not " + typeof(T).Name);
    return ConvertBack((V)value, parameter, culture);
  }

  protected virtual T Convert(V value, P parameter,
    CultureInfo culture)
  {
    throw new NotImplementedException(
      GetType().Name + ".Convert not implemented");
  }

  protected virtual T ConvertBack(V value,
    object parameter, CultureInfo culture)
  {
    throw new NotImplementedException(
      GetType().Name + ".ConvertBack not implemented");
  }
}

public abstract class BaseValueConverter<V, T>
  : BaseValueConverter<V, T, object>
{
  protected virtual T Convert(V value, CultureInfo culture)
  {
    throw new NotImplementedException(
      GetType().Name + ".Convert not implemented");
  }

  protected virtual T ConvertBack(V value, CultureInfo culture)
  {
    throw new NotImplementedException(
      GetType().Name + ".ConvertBack not implemented");
  }

  protected sealed override T Convert(V value, 
    object parameter, CultureInfo culture)
  {
    if (parameter != null)
      throw new ArgumentException(GetType().Name
        + ".Convert: binding contains unexpected parameter");
    return Convert(value, culture);
  }

  protected sealed override T ConvertBack(V value, 
    object parameter, CultureInfo culture)
  {
    if (parameter != null)
      throw new ArgumentException(GetType().Name
        + ".ConvertBack: binding contains unexpected parameter");
    return ConvertBack(value, culture);
  }
}

I'm doing a lot of Silverlight work and one issue I've encountered is how to set the cursor to an application wide busy wait icon, and disable all the controls in the application, while a web service call is made. The first technique I tried was to wrap all the application content in a ControlControl and set the latter's IsEnabled property to false while the service call is made, also setting the cursor to Wait on the main UserControl. This doesn't look good though because the application is greyed out while it is disabled, which seems too visually aggressive.

A better technique is to place a transparent rectangle over the application content during the service call. For example, in the following XAML the Rectangle element is defined with its Cursor set to "Wait" and its Visibility set to "Collapsed" so that when the application runs the Rectangle will not affect its appearance:

<UserControl x:Class="TestBusyCursor1.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    HorizontalAlignment="Center" VerticalAlignment="Center">
  <Grid x:Name="LayoutRoot" Background="LightGray" >
    <Border BorderBrush="Black" Cursor="Arrow" >
      <StackPanel Margin="50">
        <TextBlock Margin="10" Width="300" Text="Busy Cursor 1"/>
        <TextBox Margin="10" Width="300"/>
        <Button Content="Do Something" Click="Button_Click" 
          Margin="10" HorizontalAlignment="Right"/>
      </StackPanel>
    </Border>
    <Rectangle x:Name="WaitCursor" Fill="Transparent"
      Visibility="Collapsed" HorizontalAlignment="Stretch" 
      VerticalAlignment="Stretch" Cursor="Wait"/>
  </Grid>
</UserControl>

In the code-behind the click handler sets the Visibility of the Rectangle to Visible and so because the Rectangle is defined after the other content in the Grid control it effectively overlays the other content and prevents the user from clicking on any controls underneath the Rectangle. A worker thread sleeps for 5 seconds to simulate the long-running service call, and then when this completes the visibility of the Rectangle is set to Collapsed again so the Rectangle is hidden:

using System.ComponentModel;
using System.Linq;
using System.Threading;
using System.Windows;
using System.Windows.Controls;

namespace TestBusyCursor1
{
  public partial class MainPage : UserControl
  {
    public MainPage()
    {
      InitializeComponent();
    }

    private void Button_Click(object sender, RoutedEventArgs args)
    {
      WaitCursor.Visibility = Visibility.Visible;

      var worker = new BackgroundWorker();
      worker.DoWork += (s, e) =>
      {
        // simulate making a slow web service call
        Thread.Sleep(10000);
      };

      worker.RunWorkerCompleted += (s, e) =>
      {
        Dispatcher.BeginInvoke(() =>
        {
          WaitCursor.Visibility = Visibility.Collapsed; 
        });
      };

      worker.RunWorkerAsync();
    }
  }
}

Click on the button here to see the Wait cursor and how the button and textbox cannot be clicked during the simulation of the service call:

One problem with this is that it is still possible to tab into the text box, and enter text there, while clicking on the content is prevented by the Rectangle. This can be worked around by finding all the child controls which have their IsTabStop property set to true and setting it to false for the duration of the service call:

    private void Button_Click(object sender, RoutedEventArgs args)
    {
      WaitCursor.Visibility = Visibility.Visible;
      var tabStops = LayoutRoot.GetVisuals().OfType<Control>()
        .Where(c => c.IsTabStop).ToArray();
      foreach (var tabStop in tabStops)
        tabStop.IsTabStop = false;
      var worker = new BackgroundWorker();
      worker.DoWork += (s, e) =>
      {
        // simulate making a slow web service call
        Thread.Sleep(10000);
      };

      worker.RunWorkerCompleted += (s, e) =>
      {
        Dispatcher.BeginInvoke(() =>
        {
          foreach (var control in tabStops)
            control.IsTabStop = true;
          WaitCursor.Visibility = Visibility.Collapsed;
        });
      };

      worker.RunWorkerAsync();
    }

So in this version it is not possible to tab into the text box during the service call:

There is one problem remaining: the visual state of the cursor is not changed until the mouse is moved. This can be confusing if you click on the button and move the mouse for a moment so that the Wait cursor is displayed, but then don't move the mouse after the service call. From the user's point of view it looks like the service call is continuing indefinitely. For this reason it may look better to instead use some sort of spinning icon, web browser style, to indicate that the application is busy.

I commute to work in Sheffield these days. I catch the train from Denby Dale each morning. Driving to the station was difficult today because of the snow and ice on the roads but the train was on time (photo taken with iPhone).

When I read the MSDN magazine article Functional Programming for Everyday .NET Development I was puzzled by this code:

public class AddressMap : DomainMap<Address>
{
  public AddressMap()
  {
    Map(a => a.Address1);
    Map(a => a.Address2);
    Map(a => a.AddressType);
    Map(a => a.City);
    Map(a => a.TimeZone);
    Map(a => a.StateOrProvince);
    Map(a => a.Country);
    Map(a => a.PostalCode);
  }
}

Until I read the explanation:

Fluent NHibernate never evaluates the expression a => a.Address1. Instead, it parses the expression to find the name Address1 to use in the underlying NHibernate mapping. This technique has spread widely through many recent open-source projects in the .NET space. Using Lambda expressions just to get at PropertyInfo objects and property names is frequently called static reflection.

So I wrote some sample code to see how it could be implemented:

using System;
using System.Linq.Expressions;
using System.Reflection;

class Address
{
  public string Address1 { get; set; }
  public TimeZone TimeZone { get; set; }
}

class AddressMap : DomainMap<Address>
{
  public AddressMap()
  {
    Map(a => a.Address1);
    Map(a => a.TimeZone);
  }
}

class DomainMap<T>
{
  public void Map(Expression<Func<T, object>> exp)
  {
    MemberExpression mexp = exp.Body as MemberExpression;
    PropertyInfo pinfo = mexp.Member as PropertyInfo;
    Console.WriteLine("Property name: {0} Type: {1}", 
      pinfo.Name, pinfo.PropertyType);
  }
}

class Program
{
  static void Main(string[] args)
  {
    AddressMap map = new AddressMap();
  }
}

This outputs:

Property name: Address1 Type: System.String
Property name: TimeZone Type: System.TimeZone

Using reflection it would be necessary to pass in the name of the property, which is not type safe, for example:

  public void Map(string propertyName)
  {
    PropertyInfo pinfo = typeof(T).GetProperty(propertyName);
    Console.WriteLine("Property name: {0} Type: {1}", 
      pinfo.Name, pinfo.PropertyType);
  }

Thinking back to my post on NOptFunc a while ago, where I discussed the hypothetical methodinfo operator, it seems that a propertyinfo operator would be even more useful:

public class AddressMap : DomainMap<Address>
{
  public AddressMap()
  {
    Map(propertyinfo(Address.Address1));
    Map(propertyinfo(Address.Address2));
    Map(propertyinfo(Address.AddressType));
    Map(propertyinfo(Address.City));
    Map(propertyinfo(Address.TimeZone));
    Map(propertyinfo(Address.StateOrProvince));
    Map(propertyinfo(Address.Country));
    Map(propertyinfo(Address.PostalCode));
  }
}

Thinking about threads in the previous post led to consider why the Thread class doesn't implement IDisposable. After all, there will be unmanaged resources associated with each thread, for example at least a thread handle (there is a distinction between logical and physical threads in .NET but I believe that there is usually a one-one relationship, except perhaps the CLR in SQL Server?). I wrote the following code to determine that at least one handle is associated with each instance of Thread and that it is presumably not closed until the Thread instance is finalized (I used class Foo to prove that the finalizer was being run):

class Program
{
  static void Main(string[] args)
  {
    PerformanceCounter counter = new PerformanceCounter(
      "Process", "Handle Count", "TestThreadDisposable");
    Console.WriteLine("initial: {0}", counter.NextValue());
    for (int i = 0; i < 100; i++)
    {
      new Thread(() => { }).Start();
    }
    Console.WriteLine("before GC: {0}", counter.NextValue());
    new Foo();
    GC.Collect(); // force garbage collection
    Thread.Sleep(4000); // allow finalizer thread to run
    Console.WriteLine("after GC: {0}", counter.NextValue());
  }

  class Foo
  {
    ~Foo()
    {
      Console.WriteLine("finalizer running");
    }
  }
}

The results show that a number of handles are associated with each instance of Thread but they are not released when the instance is finalized:

initial: 270
before GC: 811
finalizer running
after GC: 811

So either a reference to the Thread instance is being held internally or the handles are being cached in some other way. Either way it shows that implementing IDisposable would not make any difference, at least in the current implementation of Thread. I increased the number of threads being created and the handle count goes down at some point so there is some mechanism for closing them, as you would expect.

Regardless of this, if your program is creating so many threads that handle count becomes a problem then I guess you would have bigger problems anyway.

I saw a blog post yesterday which presented a C# class for waiting on multiple threads to terminate. The code was unnecessarily complex and inefficient and so I added a comment on a more efficient way of doing it. Shortly afterwards the post disappeared but in case anyone is wondering the way to do it is simply call Thread.Join() on each of the threads in turn, e.g. if you have a collection of threads:

foreach (Thread t in threads)
    t.Join();

This is my version of the post's sample code:

class Program
{
  static void Main(String[] args)
  {
    var threads = new List<Thread>();
    for (int i = 0; i < 10; i++)
    {
      Thread t = new Thread(name =>
        {
          for (int j = 0; j < 5; j++)
          {
            Console.WriteLine("Thread {0}, Count {1}", name, j);
            Thread.Sleep(500);
          }
          Console.WriteLine("Thread {0} Finished", name);
        });
      threads.Add(t);
      t.Start(i);
    }
    Console.WriteLine("Starting to wait...");
    foreach (Thread t in threads)
      t.Join();
    Console.WriteLine("All threads finished!");
    Console.ReadKey();
  }
}

I'm evaluating NLog 1.0 — the latest release — for a project and discovered it doesn't support integration with Visual Studio 2008. I had Visual Studio 2005 installed on another machine and after installing NLog with that version to see which files are installed, I determined the following steps successfully configure NLog for VS 2008:

1. Install NLog for .NET 2.0.
2. Download nlogtemplates.zip (contents © Jaroslaw Kowalski) and extract to My Documents\Visual Studio 2008\Templates\ItemTemplates. If you have customized the location of item templates, extract to the appropriate directory.
3. Download nlogsnippets.zip (contents © Jaroslaw Kowalski) and extract to My Documents\Visual Studio 2008\Code Snippets. If you have customized the location of snippets, extract to the appropriate directory.
4. Copy the file NLog.xsd from \Program Files\NLog\bin\net-2.0 to Program Files\Microsoft Visual Studio 9.0\Xml\Schemas to enable intellisense when editing NLog configuration.

Once this has been done you will see three NLog configuration templates under My Templates in the Add New Item dialog in VS 2008. They are:

• A configuration file that defines one File Target (typical).
• A configuration file that defines one Console Target.
• An empty configuration file.

One final point: remember to set the Copy To Output Directory property of the NLog config file to Copy Always.

After reading on inessential.com about Brent Simmons reverting to his own blogging system:

I tried Wordpress for a little while on this weblog since I wanted to have comments. And last night I switched off Wordpress, back to my homegrown static-rendering system.

For comments I'm trying out Disqus. The cool thing is that it works via Javascript includes, so I can still have a static-rendered site.

I decided to try Disqus too. It was very easy to install on my static pages, just a few minutes work modifying the page templates. Looking back through my archives I noticed I switched off comments over 5.5 years ago because of increasing amounts of spam, which was a pity because it was always good to get some feedback on posts.

I am currently writing my own blog publishing app using ASP.NET MVC and LINQ to SQL. I am sticking with static pages because performance can be a little slow with dynamic pages on a shared hosting system, and I don't want to break any of my existing links (I'm still on IIS 6 and so routing is not as flexible as it would be with IIS 7).

If you need to see the XML being returned in an XML-RPC response when you are using XML-RPC.NET, attach an event handler to the proxy's ResponseEvent and trace the content of the stream using the Debug class. If you want to see the request XML, use RequestEvent.

using System.Diagnostics;
using System.IO;
using CookComputing.XmlRpc;

[XmlRpcUrl("http://www.cookcomputing.com/xmlrpcsamples/RPC2.ashx")]
public interface IStateName : IXmlRpcProxy
{
  [XmlRpcMethod("examples.getStateName")]
  string GetStateName(int stateNumber);
}

class Program
{
  static void Main(string[] args)
  {
    IStateName proxy = XmlRpcProxyGen.Create<IStateName>();
    proxy.ResponseEvent += (sender, e) => Debug.WriteLine(
      new StreamReader(e.ResponseStream).ReadToEnd());
    string name = proxy.GetStateName(1);
  }
}

If you are using .NET 2.0 use an anonymous method:

    proxy.ResponseEvent += delegate(object sender,
      XmlRpcResponseEventArgs e)
    {
      Debug.WriteLine(new StreamReader(e.ResponseStream).ReadToEnd());
    };

I'm writing some code to display some old blog posts and after retrieving each post as a single string containing CR-LF separated lines I needed to split the string into individual lines and wrap each line with a <p> tag. I could split the string using String.Split but I wondered if it was possible to use a StringReader to generate an enumeration of the lines in the string. It turns out that StringReader doesn't support this but I wrote an extension method to supply the required functionality:

public static partial class Extensions
{
  public static IEnumerable<string> Lines(this TextReader textReader)
  {
    string line;
    while ((line = textReader.ReadLine()) != null)
      yield return line;
  }
}

The extension method is defined for the TextReader parent class of StringReader so it will also work for StreamReader, which makes it possible, for example, to generate an enumeration of the lines in a file (you could use File.ReadAllLines but that generates the array of every line in the file when it is called, whereas using an iterator means that data is read from the file as required for each yield statement).

I also needed to concatenate the strings in the sequence of lines so I wrote another extension method:

public static partial class Extensions
{
  public static string Concatenate(this IEnumerable<string> strings,
    string separator)
  {
    StringBuilder strbldr = new StringBuilder();
    foreach (string str in strings)
    {
      if (strbldr.Length > 0)
        strbldr.Append(separator);
      strbldr.Append(str);
    }
    return strbldr.ToString();
  }
}

This then allows me to write code like this:

string txt = @"one
two
three";
StringReader rdr = new StringReader(txt);
string output = rdr.Lines()
  .Where(line => line != "")
  .Select(line => "<p>" + line + "</p>")
  .Concatenate(Environment.NewLine);

I am finding that with the influence of Linq I am using a more functional style of coding, not just for manipulating data in a database but also for in-memory objects such as arrays. Treating an array as a sequence to which you can apply functions to means you can write higher level code which is easier to understand, and which is less likely to have bugs, because the code is focused on the required functionality rather than how to implement it.

Bill Venners in How Scala Changed My Programming Style describes a similar experience. His example translates to C# as follows: the imperative version:

var nameHasUpperCase = false; 
for (int i = 0; i < name.Length; i++)
{
  if (char.IsUpper(name[i]))
  {
    nameHasUpperCase = true;
    break;
  }
}

And the functional version:

var nameHasUpperCase = name.Any(c => char.IsUpper(c));

Of course, as Raganwald says in Why Why Functional Programming Matters Matters, speaking of how functional code expresses a lot more what and a lot less how, this doesn't come for free:

In general, we think this is a good thing. But it isn't free: somewhere else there is a mass of code that supports your brevity. When that extra mass of code is built into the programming language, or is baked into the standard libraries, it is nearly free and obviously a Very Good Thing. A language that doesn't just separate the concern of how but does the work for you is very close to "something for nothing" in programming.

In the case of the code above I had to write the extension methods but in a more functionally oriented language it might not be necessary to write anything extra.

In general, I wonder if a language designed to be inherently more functional, such as F#, is worth learning; not necessarily as a language for day-to-day use — it may be sometime before it achieves widespread commercial usage, if ever — but because it might feed back into using C# more effectively, moving towards a more functional style of coding where possible.

I've speculated for a long time about why C# doesn't have top-level functions, for example in this post, where the solution to the problem is rather ugly because the static functions have to be qualified by their class name, i.e. instead of this:

Rgx.Expr e = 
  Rgx.Seq(Rgx.Char('c'), 
    Rgx.Seq(Rgx.Plus(Rgx.Alt(Rgx.Char('a'), Rgx.Char('d'))), 
      Rgx.Char('r')));

It would have been nicer to write this:

Expr e = 
  Seq(Char('c'), 
    Seq(Plus(Alt(Char('a'), Char('d'))), 
      Char('r')));

So I was interested to read Eric Lippert's post Why Doesn't C# Implement "Top Level" Methods? Eric discusses the cost-benefit analysis of implementing this feature, in particular:

In this particular case, the clear user benefit was in the past not large enough to justify the complications to the language which would ensue. By restricting how different language entities nest inside each other we (1) restrict legal programs to be in a common, easily understood style, and (2) make it possible to define "identifier lookup" rules which are comprehensible, specifiable, implementable, testable and documentable.

By restricting method bodies to always be inside a struct or class, we make it easier to reason about the meaning of an unqualified identifier used in an invocation context; such a thing is always an invocable member of the current type (or a base type).

He describes how C# was originally intended to be a component-oriented language designed for large-scale application development, but that with the increasing popularity of REPL languages like F#, top-level functions are being considered for a future version of C# (with the emphasis on being considered).

Interestingly, a comment on the post notes that Java has the static import construct which allows unqualified access to static members. This allows you to import static class members either individually:

import static java.lang.Math.PI;

Or en masse:

<p>
import static java.lang.Math.*;
</p>

You can then use the imported members without qualification:

double r = cos(PI * theta);

The motivation for static import was to provide a way of avoiding the constant interface antipattern, described here by Joshua Bloch. This technique involves defining an interface which contains only static final fields. A class using these constants implements the interface and so code within the class doesn't need to qualify the constant names with a class name. Bloch provides this example:

// Constant interface antipattern - do not use!
public interface PhysicalConstants {
  // Avogadro's number (1/mol)
  static final double AVOGADROS_NUMBER   = 6.02214199e23;
  // Boltzmann constant (J/K)
  static final double BOLTZMANN_CONSTANT = 1.3806503e-23;
  // Mass of the electron (kg)
  static final double ELECTRON_MASS      = 9.10938188e-31;
}

Which is used like this:

class hello implements PhysicalConstants {
  public static void main(String[] args) {
    System.out.println("Avogadro's number is " + AVOGADROS_NUMBER);
  }
}

Fortunately or not, depending on your viewpoint, this antipattern cannot be used in C# because interfaces cannot contain fields.

One of my favourite evening hikes after a day working at home is to park at Denby Dale, walk up to Upper Denby through Hagg Wood, then round to Square Wood Reservoir and up to the old Quaker settlement of High Flatts, then down to the Upper Dearne Woodlands via New House, and so back to Denby Dale. Beautiful views of the Dearne valley during the first half, then back through the woods which are particularly beautiful in the evening sunlight. About 4 miles.

Nick Palladinos has done a follow-up to my post Functional Style Regex Engine in C# Revisited. In his post Functional style regex engine in F# he presents just that, an F# version of my C# code:

let char c (s : string) = seq { if s.Length > 0 && s.[0] = c then yield s.Substring(1) }

let (=>) l r s = seq { for sl in l s do for sr in r sl -> sr }

let (<|>) l r s = seq { yield! l s; yield! r s }

let rec (<*>) e s = seq { yield s; yield! (e => (<*>) e) s }

let (<+>) e = e => (<*>) e

// example c(a|d)+r
let pattern = char 'c' => (<+>) (char 'a' <|> char 'd') => char 'r'

An interesting difference to my C# version is the use of custom operators, particularly the => and <|> infix operators, which make for a much nicer syntax. Compare the definition of the function pattern above to this:

Rgx.Expr e = Rgx.Seq(Rgx.Char('c'), 
               Rgx.Seq(Rgx.Plus(Rgx.Alt(Rgx.Char('a'), Rgx.Char('d'))), 
                 Rgx.Char('r')));

It's also nice to be able to define functions without having to put them in a class.

I've been running Windows 7 RC as a VMWare Fusion guest machine for a week or so now. Windows 7 requires 1GB of memory and I was experiencing a lot of paging on my iMac, which only has 2GB of memory, when I was trying to run several other applications in Mac OS X at the same time. So I ordered a 2GB SO-DIMM and I just installed it. Things are running much more smoothly now.

A few days ago Simon Willison posted about his optfunc command line parsing program written in Python:

Command line parsing libraries in Python such as optparse frustrate me because I can never remember how to use them without consulting the manual. optfunc is a new experimental interface to optparse which works by introspecting a function definition (including its arguments and their default values) and using that to construct a command line argument parser.

This is the example he provides:

import optfunc
    
def upper(filename, verbose = False):
    "Usage: %prog <file> [--verbose] - output file content in uppercase"
    s = open(filename).read()
    if verbose:
        print "Processing %s bytes..." % len(s)
    print s.upper()
 
if __name__ == '__main__':
    optfunc.run(upper)

And this is the resulting command-line interface:

$ ./demo.py --help
Usage: demo.py <file> [--verbose] - output file content in uppercase
    
Options:
  -h, --help show this help message and exit
  -v, --verbose 

I've recently been experimenting with C# 4.0 and I realized that the new optional parameter and default parameter value features make possible a similar style of command line parsing. So I wrote some code to do this and the result is the NOptFunc project. Using NOptFunc the code above can be written like this in C#:

using System;
using System.IO;
using CookComputing;

class Program
{
  static void Main(string[] args)
  {
    try
    {
      NOptFunc.Run(typeof(Program).GetMethod("Run"), args);
    }
    catch (Exception ex)
    {
      Console.Error.WriteLine(ex.Message);
    }
  }

  public static void Run(string filename, bool verbose = false)
  {
    string s = File.ReadAllText(filename);
    if (verbose)
      Console.WriteLine("Processing {0} bytes...", s.Length);
    Console.WriteLine(s.ToUpper());
  }
}

In comparison to the Python code the invocation of NOptFunc.Run() is quite ugly and also suffers from potentially failing at runtime if the wrong method name is supplied. It would be nice to be able to write something like this:

      NOptFunc.Run(methodinfo(Program.Run), args);

i.e. assuming that C# had a methodinfo operator along the lines of typeof, returning an instance of MethodInfo instead of Type (overloaded methods would complicate matters, requiring something like methodinfo(Program.Run(int, string)) ). Ian Griffiths discussed this in his post Getting a MethodInfo From a Method Token:

So I get a relatively warm fuzzy feeling about using typeof - I like code that will only be able to run if it can't fail. All other things being equal, I prefer this to code that has potential runtime failure modes.

I've always been mildly perplexed that there's no equivalent way of retrieving a MethodInfo object. E.g. a hypothetical methodinfo(SomeClass.SomeMethod) operator. It's not up the top of my list of language features I want added, it just seems mildly inconsistent to have the operator for getting Type objects but not the corresponding FieldInfo and MethodInfo objects. (Interestingly, there doesn't seem to be a direct way to retrieve an EventInfo in IL, so I can't really object to that one not being in the language.)

Until recently, I had never looked into the details of this. I wasn't previously sure if this missing feature was just something C# chooses not to do, or whether it's because, it can't be done. But I recently had reason to generate some IL that does exacly this, so I can now say with confidence that it's possible, and it's just that C# doesn't supply a corresponding operator.

I've still got a lot of tidying up to do with NOptFunc, for example throwing exceptions with more useful messages and supporting --help, but the basic functionality is working.

I find I am using sequences and iterators much more these days because of the influence of Linq. Even when using manipulating arrays this often results in more robust code because you don't have to worry about boundary conditions with indices; and it is easier to pass around an iterator rather than an array and a reference to the current position within the array, or so I thought until I came across an issue with List<T>.GetEnumerator() which not is immediately obvious and which may apply to other collection classes.

I had refactored some code into a separate function, passing in the instance of List<string>.Enumerator I was using. This code illustrates the problem:

using System;
using System.Collections.Generic;

class Program
{
  static void Main(string[] args)
  {
    var list = new List<string>() { "text" };
    var iterator = list.GetEnumerator();
    iterator.MoveNext();
    Console.Write("{0} ", iterator.Current ?? "null");
    Foo(iterator);
    Console.Write("{0}", iterator.Current ?? "null");
  }

  private static void Foo(List<string>.Enumerator iterator)
  {
    iterator.MoveNext();
    Console.Write("{0} ", iterator.Current ?? "null");
  }
}

I expected that after the return from the function the state of the iterator would reflect the call to MoveNext() made in the function, i.e. in this example the output would be "text null null". But the output is actually "text null text". This seemed inexplicable until I discovered that the Enumerator<T> type returned by GetEnumerator() is a struct which means a copy of the struct is passed to the function. Presumably the position of the iterator is held in a value type, maybe an index into an array, which means that any changes to the position will not be reproduced in the original instance of the struct in the calling function.

The solution is to box the struct by casting it to an interface:

using System;
using System.Collections.Generic;

class Program
{
  static void Main(string[] args)
  {
    // ...
    var iterator = list.GetEnumerator() as IEnumerator<string>;
    // ...	
  }

  private static void Foo(IEnumerator<string> iterator)
  {
    // ...
  }
}

This ensures that the called function has access to the same instance of the struct as the calling function.

I just posted my first answer to stackoverflow. Brian Ball was getting the following error when trying to load a dll built using VS 2010 beta into the NUnit GUI:

This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. You may be attempting to load an assembly build with a later version of the CLR than the version under which NUnit is currently running.

My answer was:

I've downloaded the NUnit 2.5 source and opened the VS2008 solution in the VS2010 beta. Once the conversion finished I opened all the projects and changed the target framework setting for all the projects to ".NET Framework 4.0". I then built the solution without any errors. I can now use the NUnit GUI app to run tests built for .NET 4.0. I've not done exhaustive testing of this build so there may be problems, but for my purposes it works fine.

UPDATE

It is not necessary to rebuild NUnit. I discovered that if you add the following to the relevant NUnit application config file you can run a test dll built for .NET 4.0. Under <configuration> add:

<startup>
  <requiredRuntime version="v4.0.20506" />
</startup>

and under <runtime> add:

<loadFromRemoteSources enabled="true" />

Just adding the requireRuntime element is insufficient and results in an security related error message mentioning the loadFromRemoteSources switch. I found something about the switch on this social.msdn post, where David DeWinter wrote:

Caveat: I'm not on the security team but will attempt to answer this nonetheless...

What's happening here is that the build tasks for Silverlight are attempting to load an assembly that, in previous versions of the CLR, would classify it as a partial trust assembly based on its evidence (e.g. its zone) according to CAS policy.

In CLR 4.0, CAS policy is totally deprecated and is not even enabled by default. Under the circumstances, though, it appears the CLR throws an Exception when what would be a partial trust load in CLR 2.0 is a full trust load in CLR 4.0.

The loadFromRemoteSources switch the Exception message refers to is in the runtime element under configuration and looks like this:

<runtime>
   <loadFromRemoteSources enabled="true|false" />
</runtime>

This will not enable legacy CAS policy but will allow you (or, in this case, the build system) to load remote assemblies with the same permissions as the host AppDomain. In this case it seems as though you could modify the configuration for the build system (which I assume in this case would be Visual Studio: %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config) to enable this switch.

If you don't want to modify that configuratino then you can set the environment variable COMPLUS_EnableLegacyCASPolicy to 1, which will enable CAS Policy that was present in CLR 2.0 and also allow Silverlight to load this task.

Hope that helps. David

In the previous post I originally created the sequences based on a single value by creating an array. For example:

static Expr Nil()
{
  return s => new string[] { s };
}

However this deviates a bit from the spirit of Linq, adds an unneccessary implementation detail, the fact that an array implements IEnumerable<T>, and hard-codes the string type into the expression. The neater way to do it is to use Enumerable.Repeat():

static Expr Nil()
{
  return s => Enumerable.Repeat(s, 1);
}

In January 2007 I posted about a Functional Style Regex Engine in C#. This was an exercise in using iterators and anonymous functions in C#. I decided it was time to see if it was possible to rewrite the code using Linq.

To recap, the goal is to be able to specify a regular expression in a functional style like this:

// c(a|d)+r

Rgx.Expr e = 
  Rgx.Seq(Rgx.Char('c'), 
    Rgx.Seq(Rgx.Plus(Rgx.Alt(Rgx.Char('a'), Rgx.Char('d'))), 
      Rgx.Char('r')));

foreach (string r in e("cdar"))
  Console.WriteLine("Match with remainder: {0}", r);

Calling an instance of Expr returns an enumeration of all the matches which start at the beginning of the input string. When each of the functions is called it returns a lambda expression which takes a string parameter. The expression returns an enumeration containing the remainder for every match on the string. For example, if the lambda expression generated by Rgx.Char('x') is passed the string "xyz", the enumeration returned by the expression will contain the single string "yz", this being the remainder from the match on the character 'x'.

The rewritten class turns out to be quite neat compared to the original version which required some hackiness because the yield statement cannot be used in an anonymous block. Here it is:

using System;
using System.Collections.Generic;
using System.Linq;

class Rgx
{
  public delegate IEnumerable<string> Expr(string s);

  static Expr Nil()
  {
    return s => Enumerable.Repeat(s, 1);
  }

  static public Expr Seq(Expr l, Expr r)
  {
    return s => l(s).SelectMany(x => r(x));
  }

  static public Expr Alt(Expr l, Expr r)
  {
    return s => l(s).Concat(r(s));
  }

  static public Expr Star(Expr e)
  {
    return s => Nil()(s).Concat(Seq(e, Star(e))(s));
  }

  static public Expr Plus(Expr e)
  {
    return Seq(e, Star(e));
  }

  static public Expr Char(char c)
  {
    return s => s.Length > 0 && s[0] == c
      ? Enumerable.Repeat(s.Substring(1), 1)
      : Enumerable.Repeat("", 0);
  }
}

The implementation of Seq() made me think the most. The enumeration of match remainders from the left-hand side of the sequence is processed by the right-hand side of the sequence by using the SelectMany() function, i.e. each string in the output from the left-hand side is passed to the expression on the right-hand side, each call to the right-hand expression resulting in zero or more match remainders.

Again, this is definitely not the way to implement regular expression matching, but just an exercise in using Linq.

XML-RPC.NET is essentially concerned with making statically typed calls to XML-RPC endpoints, using interfaces as contract definitions in a similar way to WCF. However the new dynamic type in .NET 4 makes it possible to provide a clean way of making dynamically typed calls, for example like this:

dynamic client = new XmlRpcClient("http://someXmlRpcEndpont");
int returnValue = client.Add(2, 3);

The DynamicObject class in the System.Dynamic namespace makes implementing a dynamic class straightforward:

using System.Dynamic;

class XmlRpcClient : DynamicObject
{
  string endpoint;

  public XmlRpcClient(string endpoint)
  {
    this.endpoint = endpoint;
  }

  public object Invoke(string methodName, object[] args)
  {
    return 5; // actually make call to XML-RPC endpoint here
  }

  public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, 
    out object result)
  {
    result = Invoke(binder.Name, args);
    return true;
  }
}

However, the method name in XML-RPC can be an arbitrary string which is not necessarily representable as a token in C#, for example "samples.Add". JavaScript handles this case by providing an alternative syntax to access a member via a string and then make a call on it, for example:

obj["foo"]()    // get member 'foo' and call it

The dynamic type of C# does not support this, at least in the current beta, but it can be implemented:

using System.Dynamic;

class XmlRpcClient : DynamicObject
{
  // ... 

  public override bool TryGetIndex(GetIndexBinder binder, object[] indexes, 
    out object result)
  {
    result = (Func)(args => Invoke(indexes[0] as string, args));
    return true;
  }

  public delegate object Func(params object[] args);
}

So making this code possible:

dynamic client = new XmlRpcClient("http://someXmlRpcEndpont");
int returnValue = client["samples.Add"](2, 3);

I installed Windows 7 RC in VMWare Fusion today (on an iMac with 2G of memory running Mac OS X 10.4). I followed the instructions on this post on the Team Fusion blog. "Windows Easy Install" blue-screened the guest machine so I tried a custom install which worked fine.

I then installed the Visual Studio 2010 beta and found this was very sluggish with a lot of display problems. Configuring the guest machine with 3D display switched off improved the performance and fixed the display issues.

I recently investigated a bug where someone had tried to split a string into space separated words using String.Split in C#. The bug was that the code failed to handle leading/trailing spaces and sequences of more than one space in the string:

var input = " 1 22  3333  ";
var words = input.Split(' ');
foreach (var word in words) Console.Write("[" + word + "] ");

// outputs [] [1] [22] [] [3333] [] []

Not a particularly interesting bug but investigating it did throw up a couple of mildly interesting points. I first thought I would try using Regex.Split but this does not handle the leading/trailing spaces:

var words = Regex.Split(input, " +");

// outputs [] [1] [22] [3333] []

Ignoring the fact I could just call String.Trim to fix this, I tried using Regex.Matches. The interesting point here is that this doesn't compile:

var words = from match in Regex.Matches(input, (@"[^ ]+")) select match.ToString();

This is because the class MatchCollection, the type returned from Regex.Matches, doesn't implement IEnumerable<T>, only implementing IEnumerable.The fix is to add a cast for the type returned from the MatchCollection enumeration:

var words = from Match match in Regex.Matches(input, @"[^ ]+") select match.ToString();
foreach (var word in words) Console.Write("[" + word + "] ");

// outputs [1] [22] [3333]

The other interesting point is that I noticed there is no ForEach extension in Linq. For example, this doesn't compile:

words.ForEach(word => Console.Write("[" + word + "] "));

I suppose this is the case because Linq is a functional style of programming and so its operators should be side-effect free. ForEach does not fit in with this, its whole purpose being the side-effects it is used for. If you want to use ForEach in this way you can implement your own ForEach extension:

public static class MyExtensions
{
    public static void ForEach<T>(this IEnumerable<T> source, Action<T> action)
    {
        foreach (T item in source)
        {
            action(item);
        }
    }
}

Going back to the original problem, I discovered that String.Split takes an option which solves the problem:

var words = input.Split(new char[] { ' ' }, StringSplitOptions.RemoveEmptyEntries);
foreach (var word in words) Console.Write("[" + word + "] ");

// outputs [1] [22] [3333]

Injecting a logger into an object is a frequently used example of DI. I have a case where the logger I want to inject needs to know the type of the object it is being injected into, so that as part of its output it can log the type from which each log line is being output. For example in the code below, where the constructor of type Foo has a parameter of type ILogger and where the implementation of ILogger - the Logger class - has a Type parameter.

class Logger : ILogger
{
    Type _loggerClientType;

    public Logger(Type loggerClientType)
   {
        _loggerClientType = loggerClientType;
   }

    // ...
}

class Foo
{
    ILogger _logger;

    public Foo(ILogger logger)
    {
        _logger = logger;
    }

    // ...
}

I posted to the Unity discussion forum, asking if there any way of achieving this with Unity. Dan Piessens replied:

The short answer is yes, but not without writing some serious Unity extensions. You'd need to override the default parameter and property resolvers, create a resolver that gets and stores the type of the object being resolved and then adds the type into the build stack before resolution then removes it. We got it all working with an set of extensions we wrote, but it's pretty complicated and unfortunately our IP rules don't allow us to release that code.

I replied:

If I get the time I may look into doing something similar to what you have done. For now I have made the ILogger members static and marked them with a custom attribute so that at startup I can scan all the types in the assembly and initialize any attributed ILogger members I find.

When using the Unity Dependency Injection container I've found that when a resolution of a dependency fails the Message property of the resulting ResolutionFailed exception is not immediately useful if there is more than one level of dependencies being resolved. For example this code:

using System;
using System.Collections.Generic;
using Microsoft.Practices.Unity;

interface ILogger
{
}

class Foo
{
  public Foo(ILogger logger)
  {
  }
}

class Bar
{
  public Bar(Foo foo)
  {
  }
}

class Program
{
  static void Main(string[] args)
  {
    var unity = new UnityContainer();
    unity.Resolve(typeof(Bar));
  }
}

Results in the following exception message:

Resolution of the dependency failed, type = "Bar", name = "". Exception message is: The current build operation (build key Build Key[Bar, null]) failed: The parameter foo could not be resolved when attempting to call constructor Bar(Foo foo). (Strategy type BuildPlanStrategy, index 3)

The information describing why the resolution failed is hidden in the hierachy of inner exceptions. To make this easy to read I use code like the LogResolutionFailed method (just writing to the console in this example):

class Program
{
  static void Main(string[] args)
  {
    try
    {
      var unity = new UnityContainer();
      unity.Resolve(typeof(Bar));
    }
    catch (ResolutionFailedException rfex)
    {
      LogResolutionFailed(rfex);
    }
  }

  static void LogResolutionFailed(ResolutionFailedException rfex)
  {
    Console.WriteLine("ResolutionFailedException for {0} {1}", 
      rfex.TypeRequested, rfex.NameRequested);
    var messages = new Stack<string>();
    var inner = rfex.InnerException;
    while (inner != null)
    {
      if (inner is InvalidOperationException)
        Console.WriteLine(inner.Message);
      inner = inner.InnerException;
    }
  }
}

Results in the following output which makes the cause of the resolution failure more obvious:

ResolutionFailedException for Bar

The parameter foo could not be resolved when attempting to call constructor Bar(Foo foo).

The parameter logger could not be resolved when attempting to call constructor Foo(ILogger logger).

The current type, ILogger, is an interface and cannot be constructed. Are you missing a type mapping?

I'm currently working on a debugger visualizer for ResolutionFailedException so that the same information can be seen in the debugger, instead of having to drill down into the inner exceptions.

I recently had to write some unit tests to test a custom configuration section. I was using NUnit so I didn't want to use the config file that would be loaded by NUnit, for example nunit-gui.exe.config, but instead wanted to load one or more separate test config files. The solution was to use the ExeConfigurationFileMap class. For example, say I have this config file:

<configuration>
  <configSections>
    <section name="MySettings" type="MySettings, TestConfigSection" />
  </configSections>
  <MySettings
    testSetting="test" />
</configuration>

I can retrieve values from the custom section using code like this:

using System.Configuration;

public class MySettings : ConfigurationSection
{
  [ConfigurationProperty("testSetting")]
  public string TestSetting
  {
    get { return (string)this["testSetting"]; }
    set { this["testSetting"] = value; }
  }

}

class Program
{
  static void Main(string[] args)
  {
    MySettings settings
      = (MySettings)ConfigurationManager.GetSection("MySettings");
    string testSetting = settings.TestSetting;
  }
}

To unit test the MySettings class I can use an instance of ExeConfigurationFileMap to load a test config file (in this case from the current directory where the test is being run):

using System.Configuration;
using NUnit.Framework;

[TestFixture]
public class ConfigTests
{
  [Test]
  public void testSetting()
  {
    ExeConfigurationFileMap fileMap = new ExeConfigurationFileMap();
    fileMap.ExeConfigFilename = "ConfigTests.config";
    Configuration config 
      = ConfigurationManager.OpenMappedExeConfiguration(fileMap, 
        ConfigurationUserLevel.None);
    MySettings section 
      = config.GetSection("MySettings") as MySettings;
    Assert.AreEqual("test", section.TestSetting);
  }
}

When I was at the last DeveloperDeveloperDeveloper day I came across usage of the word "spike" in software development for the first time. Extreme Programming has this definition:

Create spike solutions to figure out answers to tough technical or design problems. A spike solution is a very simple program to explore potential solutions. Build a system which only addresses the problem under examination and ignore all other concerns. Most spikes are not good enough to keep, so expect to throw it away. The goal is reducing the risk of a technical problem or increase the reliability of a user story's estimate.

When a technical difficulty threatens to hold up the system's development put a pair of developers on the problem for a week or two and reduce the potential risk.

I've noticed that when a developer has a technical problem they often try to solve it in-situ to the application they are working on. I prefer to write some completely standalone code to experiment with the problem so that I am not distracted by anything else relating to the application, such as building it or testing it. So I suppose I have intuitively been doing "spikes" for a long time.

Using spikes allowed you to isolate what you are experimenting with from your application code. This makes it much easier to share the problem with someone else. For example, a friend IM's you about a problem but you cannot check or run what she is doing because of she is not allowed you to send the application code, and even if she could you would have to install the app to run her code, whereas sending a small standalone project containing spike code presents no problems.

Another advantage of using spikes is that it separates test code from production code and makes it less likely that code of prototype quality is likely to end up on the trunk. Jeremy Miller's Don't Check In Spike Code… expands on this:

Don't Check in Spike Code…

...into the trunk.

Just like the title says, do NOT check "spike" code into the source control trunk. When you do an exploratory spike, you're generally throwing good coding practices completely out the window. You're on a focused mission to "figure out how this gosh durned thing is supposed to work." The code that you write in a spike probably sucks anyway.

Do spike whenever you're unsure how to work with some new library or technology or to try out a new object structure — but put that code in a branch. As soon as the spike has achieved its purpose, put that code aside, and write all new code in the trunk using TDD and your normal coding standards. You know, the coding and design standards that you've adopted as a team because you think those standards lead to sustainable quality. But Jeremy, I could just retrofit some unit tests around the spike code and call it good! Maybe, but you better ask yourself, am I really going to put decent tests around this code? Retrofitting unit tests never results in the same quality of tests as real test first development. Besides, as I said earlier, spike code generally sucks anyway;-)

I keep a large number of test projects containing my spikes as a reference for the various techniques, framework classes, and APIs I have experimented with. K Scott Allen responded to Jeremy's post with Spike Code and Source Control, where he describes the value of storing spike code:

Here are the kinds of things I've checked into "experiments/sallen" over the years:

• Code to isolate and reproduce compiler, framework, and library bugs.
• Code written to learn a new technology, platform, or library.
• Code that I almost threw away because I was sure it would only be needed once (like a one time data import).
• UI mockups
• Code written to evaluate a product.
• Code that doesn't work (because you'll have proof 6 months later when someone else has the same idea).

I've found that keeping a dedicated area for these types of check-ins offers some advantages:

It keeps spike code out of production branches (as Jeremy suggests).

It keeps code around that you might find useful to refer to one year from now.

After someone leaves a project, their experiments live on.

It saves you from saying "I think I tried something like that last year but threw the code away".

David Lambert describes how a spike can turn into what he calls a "reference architecture":

In other words, once you've used the spike to prove that something can work, you want to use it to show others how it's done. When that happens, you're starting to turn your spike into a reference architecture, and this is a much more important beast than your normal spike. Here are some signs that your spike might really be turning into a reference architecture:

• It's documented. If you start to go through the trouble of explaining how this thing works, it's more than just a spike.
• It's got more than one revision. If you check in updates to your spike to illustrate new ideas instead of building a new spike, you're growing a reference architecture.
• It mimics the structure of your "real" application. If you go to the trouble of making your spike's project structure look substantially like your application's structure (or vice versa), there's a good chance you're going to end up with a reference architecture by the time you're done.

Code samples like this, particularly with some documentation, can be useful in explaining how to do something, often more so than a design document.

So, "spike" is a pretty obvious concept but with a little thought you can get a lot more value from it.

Following my last post on Dependency Injection Andy McMullan posted a comment to my Twitter feed:

Just read Fowler's IOC/DI page - seems he disagrees with Prasanna about the superiority of DI over Serv Locator.

In the article Inversion of Control Containers and the Dependency Injection pattern Fowler compares Service Locators and DI and presents some arguments for and against DI compared with Service Locators:

For DI:

• Easier to determine what dependencies a component has - look at constructor.
• Component does not have dependency on Service Locator so there is not a problem if the component is used with a different framework.
• DI may make testing easier but a good Service Locator mechanism will make stubbing equally feasible

Against DI:

• Harder to debug and understand.
• Component cannot request extra services from injector once it had been configured.

In Concluding Thoughts Fowler says:

… Dependency Injection is a useful alternative to Service Locator. When building application classes the two are roughly equivalent, but I think Service Locator has a slight edge due to its more straightforward behavior. However if you are building classes to be used in multiple applications then Dependency Injection is a better choice.

…

The choice between Service Locator and Dependency Injection is less important than the principle of separating service configuration from the use of services within an application.

In the draft chapter I mentioned in my previous post Dhanji R. Prasanna writes:

Unfortunately, being a kind of factory, service locators suffer from the same problems of testability (or lack thereof) and shared state. The keys used to identify a service are also opaque and can be quite confusing to work with (as anyone who has used JNDI can attest). If a key is bound improperly, then the wrong type of object may be created and this error is found out only at runtime. The practice of embedding information about the service within its key (viz., "JapaneseEmailerWithPhoneAndEmail") is also unclear and places too much emphasis on arbitrary conventions.

I don't think these points are particularly compelling: binding the key incorrectly need not be a concern if, instead of a key string, a type parameter or a generic type parameter is used — for an example see the API of the Common Service Locator library — and the actual type returned from a request to the Service Locator can be configured progammatically or via a configuration file.

But I intuitively prefer the use of DI to a Service Locator. It more clearly separates the two concerns of service configuration and use of the service. It is also potentially more flexible, in that you could have a DI container which could be configured to take into account the class of the component when supplying a particular type in the component's constructor (for example, say the component needed an instance of ILogger and the implementation of ILogger needed to know the type of the component it was going to be logging). In the case where the component needs to request services after its constructor has been called, the component can be supplied with an instance of a provider class.

I've become a big fan of Dependency Injection over the last few months. I was adding new functionality to a large .NET application which had not been designed with unit testing in mind and I found it difficult to create unit tests for the new components I was writing. I had to use a ServiceLocator type mechanism which could be configured during unit testing to supply mock types. Getting this into place required a substantial amount of work on top of the new functionality I was implementing. I am now using the Unity DI container on another project and finding that DI really does make a difference, separating the provision of services to classes from the functional structure of the application.

During this time I came across the Google Testing Blog. I found a lot of useful posts on here, particularly those by Miško Hevery, which helped clarify why the legacy code I was working with was so difficult to test.

Via Mike Hadlow, I discovered a couple of days ago that Dhanji R. Prasanna, another engineer at Google, is working on a book called Dependency Injection which looks interesting. A draft of the first chapter is available free online and is worth reading if you want an introduction to Dependency Injection.

While in the vicinity of System.Globalization, a quick tip, something I used the other day for the first time, on how to convert from a Locale ID, or LCID, to the corresponding locale name: just use the constructor of the CultureInfo class which takes an LCID:

CultureInfo ci = new CultureInfo(0x809);
Console.WriteLine(ci.Name);
Assert.AreEqual("en-GB", ci.Name);

And going the other way:

CultureInfo ci = new CultureInfo("en-GB");
Console.WriteLine("0x{0:X}", ci.LCID);
Assert.AreEqual(0x809, ci.LCID);

While writing the post yesterday on Expression<TDelegate> another post from Brad Abrams in his Framework Design Guidelines series — Overriding Object.ToString() — triggered my curiosity, this time about the difference between CurrentCulture and CurrentUICulture:

DO string formatting based on the current thread culture when returning culture-dependent information.

To be more explicit, use the CultureInfo instance returned by a thread’s CurrentCulture property to format any numeric or date, and the one returned by CurrentUICulture to look up any resource. People are often confused between the two properties.

The difference seems to be that CurrentCulture is concerned with internationalization, determining how things such as numbers, currencies, dates, and time are formatted, whereas CurrentUICulture is concerned with localization, determining which language related resources are used to display text in dialogs, menus, etc.

The default value of CultureInfo.CurrentCulture is determined by the regional options for the current user. This is configured using the Regional Options tab in the Regional and Language Options Control Panel applet. On my machine with XP installed I have about 160 different regions to choose from, from Afrikaans to Zulu. The default value of CurrentCulture corresponds to Win32 GetUserDefaultLCID.

The default value of CultureInfo.CurrentUICulture is determined by the the configured UI language for the current user on an MUI version of Windows and the installed language for a localized version of Windows. The default corresponds to Win32 GetUserDefaultUILanguage. On a MUI version of Windows it is configured using the Languages tab of the Regional and Language Options applet.

There is also CultureInfo.InstalledUICulture. This is determined by the UI language for the installed version of Windows. It corresponds to Win32 GetSystemDefaultUILanguage.

CurrentCulture and CurrentUICulture can be set using the corresponding instance properties of the Thread class:

Thread.CurrentThread.CurrentUICulture = new CultureInfo("fr-FR");
Thread.CurrentThread.CurrentCulture = new CultureInfo("fr-FR");

Note that there is no way of configuring the properties globally for an application. To use non-default values the properties must be explicitly set on every relevant thread.

So, assuming we have the appropriate resources attached to our assembly, we can specify the way numbers, currencies, dates, etc, are displayed independently of which language is used for our UI:

var resMan = new ResourceManager("TestCulture.TestCulture", 
  System.Reflection.Assembly.GetExecutingAssembly());
DateTime dateTime = new DateTime(2008, 12, 25);

Thread.CurrentThread.CurrentUICulture = new CultureInfo("fr-FR");
Thread.CurrentThread.CurrentCulture = new CultureInfo("fr-FR");
string hello = resMan.GetString("Hello");
Console.WriteLine("{0}, {1:d}", hello, dateTime);
// displays "Bonjour, 25/12/2008"

Thread.CurrentThread.CurrentCulture = new CultureInfo("en-US");
Console.WriteLine("{0}, {1:d}", hello, dateTime);
// displays "Bonjour, 12/25/2008"

Thread.CurrentThread.CurrentUICulture = new CultureInfo("en-US");
hello = resMan.GetString("Hello");
Console.WriteLine("{0}, {1:d}", hello, dateTime);
// displays "Hi, 12/25/2008"

Brad Abram's post Avoiding Custom Delegates, which I linked to in an earlier post, also mentions the Expression<TDelegate> class.

Expression<…> represents function definitions that can be compiled and subsequently invoked at runtime but can also be serialized and passed to remote processes.

Expression<TDelegate> takes a delegate type as its generic parameter and is created by assigning from a lambda expression.

using System.Collections.ObjectModel;

namespace System.Linq.Expressions
{
  // Summary:
  //     Represents a strongly typed lambda expression as a data structure in the
  //     form of an expression tree. This class cannot be inherited.
  //
  // Type parameters:
  //   TDelegate:
  //     The type of the delegate that the System.Linq.Expressions.Expression<TDelegate>
  //     represents.
  public sealed class Expression<TDelegate> : LambdaExpression
  {
    // Summary:
    //     Compiles the lambda expression described by the expression tree into executable
    //     code.
    //
    // Returns:
    //     A delegate of type TDelegate that represents the lambda expression described
    //     by the System.Linq.Expressions.Expression<TDelegate>.
    public TDelegate Compile();
  }
}

For example:

Expression<Func<int, bool>> exprTree = num => num < 5;

The compiler is implemented such that when it has to compile an assignment like this to Expression, instead of compiling the lambda expression to IL code it constructs an "expression tree", a type of abstract syntax tree (AST). This sample code from MSDN illustrates what happens:

Expression<Func<int, bool>> exprTree = num => num < 5;

// Decompose the expression tree.
ParameterExpression param = (ParameterExpression)exprTree.Parameters[0];
BinaryExpression operation = (BinaryExpression)exprTree.Body;
ParameterExpression left = (ParameterExpression)operation.Left;
ConstantExpression right = (ConstantExpression)operation.Right;

Console.WriteLine("Decomposed expression: {0} => {1} {2} {3}",
                      param.Name, left.Name, operation.NodeType, right.Value);
/*
console output is:

Decomposed expression: num => num LessThan 5

*/

The Compile method of Expression<TDelegate> can be called to create a delegate of the instance's generic type:

Func<int, bool> func = exprTree.Compile();
Assert.AreEqual(true, func(3));

The advantage of using Expression<TDelegate> is that if the methods of an API take instances of this instead of delegates, the implementation of the API can optimize the processing of the expression tree at runtime. For example, in Linq to SQL many of the methods of the IQueryable interface take Expression<TDelegate> so that optimized SQL can be generated at runtime. This can make a huge difference to the performance of Linq expressions.

Note that Expression<TDelegate> can only be assigned a lambda expression with an expression body. You cannot assign a lambda expression or an anonymous delegate:

// does not compile
Expression<Func<int, bool>> exprTree2 = num => { return num < 5; };
    
// does not compile
Expression<Func<int, bool>> exprTree3 = delegate(int num) { return num < 5; };

The previous post explained that using the PreAuthenticate property of System.Net.WebRequest does not prevent two round-trips when making the first request for an HTTP resource protected by Basic Authentication. The workaround for this is to generate and set the HTTP Authorization header explicitly like this:

  static string CreateAuthorization(string realm,
    string userName, string password)
  {
    string auth = ((realm != null) && (realm.Length > 0) ?
    realm + @"\" : "") + userName + ":" + password;
    auth = Convert.ToBase64String(Encoding.Default.GetBytes(auth));
    return auth;
  }

The return value from this function can be used to set the Authorization header:

    WebRequest req = WebRequest.Create(uri);
    string auth = CreateAuthorization("cookcomputing.com", "user",
      "password");
    req.Headers["Authorization"] = "Basic " + auth;

This will result in a single round-trip for each request:

• Client: GET /foo/foo.html HTTP/1.1
  Authorization: Basic c3RvY2tsZXkuYXZheWEuY29tXGNoY29vazpBcmVuaWcxNjAh
• Server: HTTP/1.1 200 OK
• Client: GET /foo/bar.html HTTP/1.1
  Authorization: Basic c3RvY2tsZXkuYXZheWEuY29tXGNoY29vazpBcmVuaWcxNjAh
• Server: HTTP/1.1 200 OK

The same technique can be used with XML-RPC.NET, for example:

using System;
using System.Text;
using CookComputing.XmlRpc;

[XmlRpcUrl("http://localhost:81/xmlrpc/RPC2.ashx")]
public interface IStateName : IXmlRpcProxy
{
  [XmlRpcMethod("examples.getStateName")]
  string GetStateName(int stateNumber);
}

class Program
{
  static string CreateAuthorization(string realm, 
    string userName, string password)
  {
    string auth = ((realm != null) && (realm.Length > 0) ?
    realm + @"\" : "") + userName + ":" + password;
    auth = Convert.ToBase64String(Encoding.Default.GetBytes(auth));
    return auth;
  }

  static void Main(string[] args)
  {
    IStateName proxy = XmlRpcProxyGen.Create<IStateName>();
    string auth = CreateAuthorization("cookcomputing.com", "user", "password");
    proxy.Headers["Authorization"] = "Basic " + auth;
    string ret = proxy.GetStateName(1);
  }
}

There is a common misunderstanding about how the PreAuthenticate property of .NET's System.Net.WebRequest class works, for example when using Basic Authentication. In this post I'll explain how it actually works and in the next post I'll describe how to use WebRequest to get the behaviour that is often erroneously expected when PreAuthenticate is used. Say this code is used to retrieve two HTTP resources:

using System;
using System.IO;
using System.Net;

class Program
{
  static string Get(string uri)
  {
    WebRequest req = WebRequest.Create(uri);
    req.Credentials = new NetworkCredential("user", "password", 
        "cookcomputing.com");
    req.PreAuthenticate = false; // default for WebRequest
    Stream stm = req.GetResponse().GetResponseStream();
    string ret = new StreamReader(stm).ReadToEnd();
    return ret;
  }

  static void Main(string[] args)
  {
    Console.WriteLine(Get("http://localhost:81/foo/foo.html"));
    Console.WriteLine(Get("http://localhost:81/foo/bar.html"));
  }
}

There will be four round-trips between the client and server (for the time being assume the server does not have HTTP Keep-Alive enabled):

• Client: GET /foo/foo.html HTTP/1.1
• Server: HTTP/1.1 401 Access Denied
  WWW-Authenticate: Basic realm=" cookcomputing.com"
• Client: GET /foo/foo.html HTTP/1.1
  Authorization: Basic c3RvY2tsZXkuYXZheWEuY29tXGNoY29vazpBcmVuaWcxNjAh
• Server: HTTP/1.1 200 OK
• Client: GET /foo/bar.html HTTP/1.1
• Server: HTTP/1.1 401 Access Denied
  WWW-Authenticate: Basic realm="cookcomputing.com"
• Client: GET /foo/bar.html HTTP/1.1
  Authorization: Basic c3RvY2tsZXkuYXZheWEuY29tXGNoY29vazpBcmVuaWcxNjAh
• Server: HTTP/1.1 200 OK

    req.PreAuthenticate = true;

In fact this is what actually happens:

• Client: GET /foo/foo.html HTTP/1.1
• Server: HTTP/1.1 401 Access Denied
  WWW-Authenticate: Basic realm=" cookcomputing.com"
• Client: GET /foo/foo.html HTTP/1.1
  Authorization: Basic c3RvY2tsZXkuYXZheWEuY29tXGNoY29vazpBcmVuaWcxNjAh
• Server: HTTP/1.1 200 OK
• Client: GET /foo/bar.html HTTP/1.1
• Server: HTTP/1.1 200 OK

Note that if the server has enabled HTTP KeepAlive and the default value of true for HttpWebRequest.KeepAlive has not been changed, then assuming the connection remains open for the second request, the successful authorization for the first request will still apply and the use of PreAuthenticate is not required.

I've been using the Func<...> and Action<...> delegates for a while now but I recently declared a custom delegate where I could have used Action<...>. Brad Abram's post Framework Design Guidelines: Avoiding custom delegates prompted me to change my code.

For reference here are the different versions of Action and Func:

public delegate void Action()
public delegate void Action<T1>(T1 arg1)
public delegate void Action<T1, T2>(T1 arg1, T2 arg2)
public delegate void Action<T1, T2, T3>(T1 arg1, T2 arg2, T3 arg3)
public delegate void Action<T1, T2, T3, T4>(T1 arg1, T2 arg2, T3 arg3, T4 arg4)
public delegate TResult Func<TResult>()
public delegate TResult Func<T, TResult>(T arg)
public delegate TResult Func<T1, T2, TResult>(T1 arg1, T2 arg2)
public delegate TResult Func<T1, T2, T3, TResult>(T1 arg1, T2 arg2, T3 arg3)
public delegate TResult Func<T1, T2, T3, T4, TResult>(T1 arg1, T2 arg2, T3 arg3, T4 arg4)

I've just started using Unity (v1.2) and in one scenario I need to be able to configure Unity with a factory for a type, rather than default to Unity creating an object of the type configured for the requested type. In my case the object implementing the interface is a Remoting proxy but say, for example, I have interface IFoo implemented by class Foo and I want instances of IFoo returned by Unity to be instances of Foo created by a factory class:

interface IFoo
{
  void DoFoo();
}

class Foo : IFoo
{
  public void DoFoo()
  {
    Console.WriteLine("DoFoo: CreatedBy = {0}", CreatedBy);
  }
  public string CreatedBy { get; set; }
}

class FooFactory
{
  static public IFoo CreateInstance()
  {
    Console.WriteLine("CreateInstance");
    var foo = new Foo();
    foo.CreatedBy = "Factory";
    return foo;
  }
}

The solution is to use Unity's StaticFactoryExtension. After creating the container, add the extension to the container and then register the factory:

using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.StaticFactory;
// ...
IUnityContainer container = new UnityContainer();
container.AddNewExtension<StaticFactoryExtension>(); 
IStaticFactoryConfiguration config
  = container.Configure<IStaticFactoryConfiguration>();
config.RegisterFactory<IFoo>(unity => FooFactory.CreateInstance());

Finally we can request an instance of IFoo from the container:

IFoo foo = container.Resolve<IFoo>();
foo.DoFoo();

The following assembly references are required:

• Microsoft.Practices.ObjectBuilder2
• Microsoft.Practices.Unity
• Microsoft.Practices.Unity.StaticFactory

I am currently modifiying XML-RPC.NET to support Silverlight 2. One problem I encountered is that when you use XmlWriter.Create to create an XML writer on top of a stream it is not possible pass a null encoding to specify that you don't want an encoding attribute in the XML declaration at the start of the document.

By default a StreamWriter created on top of the stream will result in an encoding of "utf-8". For example this program:

class Program
{
  static void Main(string[] args)
  {
    FileStream stm = new FileStream(@"c:\temp\test.xml",
        FileMode.OpenOrCreate | FileMode.Truncate);
    WriteXml(stm);
  }

  static void WriteXml(Stream stm)
  {
    var stmWriter = new StreamWriter(stm);
    var settings = new XmlWriterSettings();
    var xmlWriter = XmlWriter.Create(stmWriter, settings);
    xmlWriter.WriteStartDocument();
    xmlWriter.WriteElementString("foo", "bar");
    xmlWriter.Close();
  }
}

Creates this document:

<?xml version="1.0" encoding="utf-8"?><foo>bar</foo>

If you try to specify a null encoding:

    StreamWriter stmWriter = new StreamWriter(stm, null);

An instance of ArgumentNullException is thrown. A solution is to derive a class from StreamWriter and override the Encoding property:

public class EncodingStreamWriter : StreamWriter
{
  Encoding _encoding;

  public EncodingStreamWriter(Stream stm, Encoding encoding)
    : base(stm)
  {
    _encoding = encoding;
  }

  public override Encoding Encoding
  {
    get { return _encoding; }
  }
}

And then use this instead of StreamWriter:

    var stmWriter = new EncodingStreamWriter(stm, null);

To create the desired XML document:

<?xml version="1.0"?><foo>bar</foo>

I've just been trying to get a Silverlight control to make a cross-domain HTTP POST call using an experimental Silverlight build of XML-RPC.NET. I placed a client access policy file on the root of the server but I was still getting a System.Security.SecurityException when I tried to make the call. I eventually worked out the cause of the problem was that when I created the Silverlight project in Visual Studio I selected "Automatically generate a test page to host Silverlight at build time". This results in the page being loaded using the file:// scheme when debugging, and cross-scheme access is not allowed in this case, i.e. file:// to http://, even with a client access policy file on the server.

I created another project and this time chose the option to add a web project to the solution. The cross-domain calls, now http:// to http://, succeeded.

#light

open CookComputing.XmlRpc

type Request = { state1 : int; state2 : int; state3 : int; }

[<XmlRpcUrl("http://www.cookcomputing.com/xmlrpcsamples/RPC2.ashx")>]
type IStateName = 
    [<XmlRpcMethod("examples.getStateName")>]
    abstract GetStateName : number: int -> string
    [<XmlRpcMethod("examples.getStateStruct")>]
    abstract GetStateNames : request: Request -> string

let proxy = XmlRpcProxyGen.Create<IStateName>()
let name = proxy.GetStateName(1)
printfn "name is %s" name
let request = { state1 = 1; state2 = 2; state3 = 3; }
let names = proxy.GetStateNames(request)
printfn "names are %s" names