So I'm looking at some code that's failing, using the immediate window in Visual Studio. I type an expression:

parent.Children.Where(c => c.Property != 42)

... and Visual Studio responds with:

Expression cannot contain lambda expressions

It turns out that this is by design. Neat. No script/console equivalent for me :-( Maybe if enough of us up-vote that Connect issue MS might decide to bring VS into the 21st century.

Visual Studio 2010 now - finally - has column editing; see Visual Studio 2010 - Box Selection for instructions. It's gradually catching up to Emacs in some respects ;-)

MSDN defines Double.MinValue as representing "... the smallest possible value of a Double."

  double.Parse(string.IsNullOrWhiteSpace(text) ? double.MinValue.ToString() : text);

However, the above fails when text is "", because double.Parse() fails on double.MinValue.ToString(), claiming that it's too small to be a double. Clearly, MinValue meant two different things to two different developers at Microsoft :-)

I've replaced it with:

  double result;
  if (!double.TryParse(text, out result))
  {
    result = double.MinValue;
  }

... which works nicely.

We just shifted from using HTTP GET to HTTP POST for some of our web services; in this case, we are POSTing from a .NET 2.0 application to a Ruby on Rails server running on Lighttpd (a.k.a. lighty).

This resulted in an HTTP 417 error.

This is caused by the Microsoft .NET WebClient class adding an expect header into the POST, which in turn causes Lighttpd 1.4 to fail. The fix (as explained by Phil Haack) is to make the following call before POSTing:

System.Net.ServicePointManager.Expect100Continue = false;

At OffByZero, we use a wide range of operating systems including Ubuntu Linux, Mac OS X, and MS Windows. We also have a wide range of passwords and other business secrets that we must store securely.

Recently we went looking for a secure text editor that ran on all those OSs, offered an easy installation process and good user experience, and could be run entirely out of a source control checkout. We found nothing, so we wrote our own, with the intent of productizing it after we had dogfooded it ourselves.

It didn't work out exactly that way; we ended up writing three.

The first version was written in C#, and intended to run on Linux and Mac OS X using Mono. Sadly it suffered from several unresolved Mono bugs that made it unworkable on anything but MS Windows - and hence failed to offer a cross-plaftorm solution. The second version was reworked from the first to avoid the aforementioned Mono UI bugs; however it ran aground on a new set of Mono bugs, including astonishingly bad performance on Mac OS X.

So, we decided to re-write in Java and Swing. The process was relatively painless (it took longer to develop the installers for our supported OSs than it did to write the application in the first place), and we were left with a simple, secure text editor that we trust to store all of our important secrets.

Today, we're celebrating the release of OBZVault 3.2. Hopefully people will find it as useful as we have.

Windows Vista	Mac OS X 10.4	Ubuntu 9.04

We are about to release a product that is a built upon an internal tool we've been using for a while. One of the strengths of the product is that it runs on MS Windows, Linux and MacOSX through the wonders of Mono.

However we're being blocked by a bug in Mono itself; whenever I try to create an instance of the PageSetupDialog path, I get a NullReferenceException thrown by get_UseYardPound.

Anyhow, I've submitted it to the Mono team as Bug 499630, and I'll post any updates or workarounds as I learn them.

At the moment, my solution is to disable printing if the exception is thrown - which means the app is stable, but less functional on MacOSX. It's been one of those days, really ... :-(

Okay, so I'm trying to tweak SubSonic to emit nested domain objects that can be serialized by the Microsoft SOAP serializers. My particular gripe is with the fact that child records are exposed as methods:

  public OBZ.Database.MyChildCollection MyChildRecords        
  {
    return new OBZ.Database.MyChildCollection().Where(MyChild.Columns.ThingId, ThingId).Load();
  }

... whereas I need them exposed as properties:

  [XmlArray]
  public OBZ.Database.MyChildCollection  MyChildRecords        
  {
    get
    {
      return new OBZ.Database.MyChildCollection().Where(MyChild.Columns.ThingId, ThingId).Load();
    }
  }

Now, I'm pretty sure that this is just a matter of editing some templates somewhere and regenerating my database classes. In other words, this post isn't intended to be a criticism of SubSonic. Quite the contrary in fact. I love SubSonic to bits and will be contributing a patch or two to it when (if?) I have the time.

However, this got me to thinking of how easy it'd be to add a couple of get accessors to these classes if I was using Ruby (or really any dynamic language with strong metaprogramming).

Here's a simple example, where I use the interactive Ruby tool (irb) to extend the String class:

  irb(main):001:0> class String
  irb(main):002:1>   def barf
  irb(main):003:2>     "Bananas"
  irb(main):004:2>   end
  irb(main):005:1> end
  => nil
  irb(main):006:0> a = "Hello"
  => "Hello"
  irb(main):007:0> a.barf
  => "Bananas"

As you can see, once I've added barf to the String class, any subsequent Strings I instantiate expose barf for me to use. It doesn't take much imagination to see that I could use this to easily extract myself from the class of problem I'm having with SubSonic. (I'll grant you that I wouldn't be having that problem in the first place if I was using Ruby, as you might have noticed from my example that a get accessor is just a method, but that's a topic for another day).

How about C#? Well, it offers extension methods but note they're methods not properties, so that's no help. I could use the System.Reflection.Emit namespace to create a new class that inherits from the SubSonic-generated class, or I could simply create a new class that inherits from the SubSonic-generated classes and contains the properties I need. The problem is that System.Reflection.Emit is just a little bit more verbose than the Ruby alternative, and both that and inheritance are fixing the problem by creating a new class, rather than just extending an existing one.

The more I use Ruby, the more I'm coming to value dynamic languages in general, and Ruby in particular.

It turns out that you shouldn't ever construct a WPF window inside the constructor of another. If you do, the application will hang indefinitely on exit. That is, the first window will disappear, but the process will continue running.

The following code can be used to reproduce the hang:

    public partial class Window1 : Window
    {
        private Window2 window2;

        public Window1()
        {
            InitializeComponent();
            window2 = new Window2();
        }
    }

You can also see a screencast of this bug in action, courtesy Jing (I'm very pleased with Jing; I also used it to create the OBZTime screencast and wholeheartedly recommend it for quick & easy screencasts if you can handle the Jing logo at the end).

Update 14/08/2008: There's a discussion thread on this issue on MSDN Forums with details on how to solve this problem.

It turns out that I was dead wrong about the cause; it has nothing to do with the nested constructors. I was counting on the application closing when the last shown window was closed, but instead the default behaviour is to count constructed windows.

Personally I think Hua was being a little generous when he said that to have this behaviour as default is "debatable" :-)

Anyway, the fixed code looks like this:

    public partial class Window1 : Window
    {
        private Window2 window2;

        public Window1()
        {
            InitializeComponent();

            Application.Current.ShutdownMode = ShutdownMode.OnMainWindowClose;
            window2 = new Window2();
        }
    }

<rant>Here's a hint to software developers everywhere - if you're using a type that confers no meta-information about the value it represents (say, a double for a time interval instead of a TimeSpan), do be good enough to document it:

I mean, what's the interval unit here? Milliseconds? Minutes? Hours? There is simply no way to know without ratting through MSDN, which is fine, but Intellisense is supposed to resolve this sort of simple ambiguity without the need for extra documentation.</rant>

I know I've been promising a full NPresent tutorial for a while now - and I'm still planning to post one. In the meantime however I thought I'd quickly demonstrate how I've been using C# Script (a great scripting engine for C# developed by Oleg Shilo) to automate WPF smoke-tests as part of our NAnt build. This required a new release of NPresent that can attach to existing windows; you can get it here.