I'm slowly converting a number of blogs from Blogger to BlogEngine.NET. The least fun part is dealing with the Blogger export file. For this blog I used a Powershell script but had problems with comments not exporting correctly and it was quite painful to fix everything up. Blogger allows you to export a copy of your blog using ATOM, however BlogEngine.NET (and other tools) speak BlogML.
I've just released a command line tool that takes the ATOM format Blogger export and converts it to BlogML. You can download Blogger2BlogML from Codeplex. The tool uses .NET 4.0 (client profile) so you'll need to install this if you don't already have it. If you give Blogger2BlogML a try let me know how you get on.
I've just released a small update for my ESRI Shapefile Reader project on Codeplex. The only change is a patch from SolutionMania that fixes a problem when the shapefile name is also a reserved name in the metadata database. The patch escapes the name preventing an exception from being thrown.
Catfood.Shapefile.dll is a .NET 2.0 forward only parser for reading an ESRI Shapefile. Download 1.20 from Codeplex.
I've been going nuts trying to scan from the document feeder on my Canon imageClass MF4150. Everything worked as expected from the flatbed, no dice trying to persuade the ADF to kick in. I found some sample code but it was oriented towards devices that can detect when a document is available in the feeder. Evidently my Canon doesn't expose this and so needs to be told the source to use.
The way to do this is to set the WIA_DPS_DOCUMENT_HANDLING_SELECT property to FEEDER. You then read WIA_DPS_DOCUMENT_HANDLING_STATUS to check that it's in the right mode and initiate the scan. This did not work for toffee.
After much experimentation I discovered a solution. I had been setting device properties and then setting item properties before requesting the scan. Switching the order - item then device - made everything work.
Here's the function to scan one page:
After floundering a bit with the WPF Dispatcher I've come up with a simple way to make sure an event handler executes on the UI thread without paying the overhead of always invoking a delegate.
void someEvent_Handler(object sender, SomeEventEventArgs e)
// do work on UI thread
// or BeginInvoke()
this.Dispatcher.Invoke(new Action<object, SomeEventEventArgs>(someEvent_Handler),
This has the benefit (for me at least) of being very easy to remember. Hook up the event handler and then if there's a chance it could be called from a different thread wrap it using the pattern above. It's easier to read than an anonymous delegate and much faster than defining a specific delegate for the event in question.
I haven't tested the various methods to see which is the fastest yet… will get round to this at some point.
When testing out a WPF app on XP I got an unhelpful XamlParseException error report.
I was a little puzzled because I was hooking up error reporting in App.xaml.cs:
My error handler was attempting to create a XAML window to report the error, and evidently this was bombing out as well triggering the good doctor Watson. I added a MessageBox call instead and discovered that the XamlParseException was wrapping a FileFormatException and the stack trace indicated that the problem was with setting the icon for the window. After removing the icon the app started up fine. Weird.
It turns out that WPF chokes on a compressed 256x256 icon on XP and Vista (Windows 7 seems to cope fine). Saving the icon without compression fixes the problem. I use IcoFX and you can set this at Options -> Preferences -> Options -> Compress 256x256 images for Windows Vista. Of course the consequence is that the icon is a couple of hundred kilobytes larger.
I've spent the last day learning how to use OAuth and XAuth to post to Twitter. There are rumblings that Twitter will start to phase out basic authentication later this year, and more importantly you can only get the nice “via...” attribution if you use OAuth (for new apps, old ones are grandfathered in).
I coded up my own OAuth implementation, referring to Twitter Development: The OAuth Specification on Wrox and the OAuthBase.cs class from the oauth project on Google Code. Both are great references, but both fail with multibyte characters. The problem is that each byte needs to be separately escaped. OAuthBase.cs encodes characters as ints rather than breaking out the bytes and the Wrox article incorrectly suggests using Uri.EscapeDataString().
Here's a method to correctly encode parameters for OAuth:
public static string OAuthUrlEncode(string s)
StringBuilder sb = new StringBuilder(s.Length);
for (int i = 0; i < s.Length; i++)
if (NoEncodeChars.IndexOf(s[i]) == -1)
// character needs encoding
byte characterBytes = Encoding.UTF8.GetBytes(s[i].ToString());
for (int b = 0; b < characterBytes.Length; b++)
// character is allowed
NoEncode chars is a list of the permitted characters:
private const string NoEncodeChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-_.~";
An impact of this encoding is that spaces must be encoded as %20 rather than plus. I was worried that each space would end up counting as three characters towards the 140 character limit. I tested this and it isn't true, so use HttpUtility.UrlEncode() to calculate the number of characters in the post OAuthUrlEncode() or similar to actually encode post parameter.
I finished off my BlogEngine.NET migration yesterday missing a couple of useful sections from the previous incarnation of this blog. The first is a list of the most popular posts based on Google Analytics data. I've just finished porting this from a UserControl to a widget for BlogEngine.NET. To use this just download and extract this zip file to your widgets directory:
MostPopularFromGA.zip (5.22 kb)
You can see the widget in action under the Most Popular heading to the left if you're reading this post on the blog.