There's a new version of Windows Live Messenger - v8.5.1302.1018 and the RTM of Windows Live Writer.

Get them both from the one installer.

I'm using Live Writer to create most of my blog posts now - it's a really nice editor, and you can tell it to generate XHTML (go to your weblog settings, look in the Advanced section and click XHTML).

It would be me that happens to make the Visual Basic compiler crash!

As I've mentioned in the Rhino Mocks group, the crash appears to be caused by an interesting combination of a generic interface, another interface that inherits from the generic one, and a mock object that implements that interface. When you then try to use the new void method handling code (a new feature of Rhino Mocks 3.3) the compiler barfs (that's a compiler technical term).

I've attached a simple project to the MS bug report that reproduces the crash. Please contact me if you are interested in the code.

The workaround is to revert to the pre-3.3 way of handing void method expectations:

eg. instead of this:

Using Mocks.Record()

 Expect.Call(MockedObject.Subroutine)

End Using

Do this:

Using Mocks.Record()

 MockedObject.Subroutine

End Using

As we arrived at Church on Sunday, I was greeted by a number of people saying, "We saw you in the paper today!"

So while I didn't get a mention from Thursday's interview on the day, apparently my mug is in the paper edition, along with along with some of my comments (down under the Belair sub-heading).

To be fair to the Sunday Mail, they are being pretty open about the fact that they were the ones handing out the badges, and I think I've been quoted accurately, which is reassuring.

(Photo from Sunday Mail, 4th November 2007)

Today at Blackwood Train station, I was interviewed by a Sunday Mail journalist.

Apparently they are running a campaign to encourage more investment in public transport, particularly after the problems the trains had yesterday with the computer system failing completely.

I didn't make the copy in the final article - oh well.

Looks like I will need to get Owen's autograph after all (he's the guy on the left). I was sitting just out of shot behind the guy standing up near the door on the right :-)

I read about the release of Binsor 2.0, and thought that might be really handy for a current project. The problem is that you need to compile it yourself.

This was causing me a few headaches and one late night after a countless false starts I gave up and posted to the Rhino Tools Dev group.

Prerequisites

You will need the command-line SVN tools (even if you already have TortoiseSVN).

Directory layout

I've used the following directory layout (with SVN repository paths):

• OSS
  • Castle-Trunk (http://svn.castleproject.org:8080/svn/castle/branches/WithNHibernate2.0-Alpha)
  • NHibernate-Trunk (https://nhibernate.svn.sourceforge.net/svnroot/nhibernate/trunk)
  • RhinoTools-Trunk (https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk)

I then saved RhinoTools-Trunk\BuildFromTrunk-Config.build.sample to BuildFromTrunk-Config.build and edited it like this:

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

<Project DefaultTargets="Update-All;Build-All;Copy-To-Artifact-Dir" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

 <!-- Configuration -->

 <PropertyGroup>

 <Configuration>debug</Configuration>

 <Enable-Tests>false</Enable-Tests>

 <!-- User Settings -->

 <Dest-Dir></Dest-Dir>

 <Dest-Lib-Dir>$(Dest-Dir)\lib\$(Configuration)</Dest-Lib-Dir>

 <Dest-Tool-Dir>$(Dest-Dir)\tools</Dest-Tool-Dir>

 <Tools-Dir>$(MSBuildProjectDirectory)\SharedLibs\Tools</Tools-Dir>

 <NH-Dir>$(MSBuildProjectDirectory)\..\NHibernate-Trunk\nhibernate</NH-Dir>

 <Castle-Dir>$(MSBuildProjectDirectory)\..\Castle-Trunk</Castle-Dir>

 <Rhino-Dir>$(MSBuildProjectDirectory)</Rhino-Dir>

 <Artifact-Dir>$(MSBuildProjectDirectory)\Trunk-Artifacts</Artifact-Dir>

 <MSBuildCommunityTasksPath>$(Tools-Dir)</MSBuildCommunityTasksPath>

 <Svn-Dir>$(Tools-Dir)\Subversion</Svn-Dir>

 </PropertyGroup>

</Project>

The final thing that caused me grief was some missing edits to RhinoTools-Trunk\rhino-commons\Rhino.Commons\Rhino.Commons.csproj. Hopefully this will be patched soon, but I had to make the following hand-edits to the csproj file:

Index: Rhino.Commons.csproj =================================================================== --- Rhino.Commons.csproj (revision 908) +++ Rhino.Commons.csproj (working copy) @@ -158,7 +158,9 @@ <Compile Include="Binsor\Extensions\StartableExtension.cs" /> <Compile Include="Binsor\Macros\AbstractBinsorMacro.cs" /> <Compile Include="Binsor\Macros\BaseBinsorExtensionMacro.cs" /> - <Compile Include="Binsor\Macros\BaseNamedBinsorMacro.cs" /> + <Compile Include="Binsor\Macros\BaseBinsorToplevelMacro.cs" /> + <Compile Include="Binsor\Macros\BaseConfigurationMacro.cs" /> + <Compile Include="Binsor\Macros\ParametersMacro.cs" /> <Compile Include="Binsor\Macros\ComponentMacro.cs" /> <Compile Include="Binsor\Macros\ComponentMethodVisitor.cs" /> <Compile Include="Binsor\Macros\ConfigurationMacro.cs" />

I then opened a Visual Studio 2005 Command Prompt ("Run as Administrator" on Vista), and entered:

msbuild BuildFromTrunk.build /t:Build-All

3 minutes and 44 odd seconds later, Rhino.Commons.dll appeared.

One thing to note, this is built of the trunks of NHibernate and Castle Project code, so those bits may or may not be as stable as the most recent public releases.