There are many blog posts online telling you how to install the .NET Framework using Inno Setup. Most of them work in most cases, but they fail to properly handle restarting the machine if the .NET Framework installer needs to restart, or handle errors encountered by the .NET Framework installer. If you put a bit more effort in (and learn a bit of Pascal!), you can write something more robust.

If you’ve ever written code which compares two DateTimes, you might be living on borrowed time. Most people assume that time ticks forwards at a rate of one second per second, and this assumption pervades a lot of our programming as well. However this isn’t always the case: the user changing their clock, or leap seconds, can cause time to jump backwards and forwards, invalidating your calculations. Even recently this caused serious issues for CloudFlare.

The solution is simple: use a monotonic time source: one that is independent of the system time, and always ticks forward at a rate of one second per second. Unfortunately .NET doesn’t expose such a time source directly. Here’s an easy way to make one.

When you’re writing XAML using the Visual Studio designer, you’ll sometimes find that it’s unable to locate resources that are stored in a ResourceDictionary (and referenced using {StaticResource}). This is a particular problem if you’re working on a class library project (rather than a WPF application), as it often won’t be able to find the correct Application to start, and so won’t load its resources. It can also happen if you’re loading ResourceDictionaries dynamically.

If you want to compare your objects for equality, you’re going to have to implement Equals and GetHashCode. There are plenty examples around of how to do this, but they tend to contradict each other. This is the pattern that I follow.

Introduction Everyone has their own opinion on how a WPF application should be internationalized. People have tried referencing resources directly using {x:Static}, using tools to parse the compiled XAML for strings, and everything in between. Each approach has advantages and disadvantages, but it’s hard to figure out what’s best for you. In my case, I couldn’t find any existing solutions which fitted my needs well, so I did what I normally end up doing and wrote my own.

Here’s a fun little gotcha.

I was creating a list of files, displayed to the user. Alongside each file I was displaying the icon associated with the file type; fetching it using SHGetFileInfo, storing the Icon instance in the ViewModel for each file entry, then converting that to a BitmapSource using a converter on the binding. Should be fine, right?

And it was fine, until a user tried to list a few thousand files.

Normally, if you want to add a custom NuGet package source, you do this from within Visual Studio: Tools -> Options -> NuGet Package Manager -> Sources. However, this means that everyone who wants to build your project has to have those same custom package sources configured, which is annoying.

App.config is a great convenient place to store the sorts of magic values that your application needs in order to run, but which you might want to change after installing, without recompiling. Using the built-in Properties\Settings.settings UI, and then accessing those with Properties.Settings.Default, is a fine way of putting custom data in App.config.

Windows 8 introduced the concept of a metered connection. A metered connection indicates that the user is being charged for data transfer on that network, and so you might want to limit how much you transfer. WinRT provides classes in the Windows.Networking.Connectivity namespace to determine whether or not a given connection is metered (and much more besides), but there’s nothing directly available in traditional .NET applications.

Beginners are often told to avoid using async void in C#, and with good reason: 90% of the time, they actually wanted async Task. They’re told to only use async void in event handlers, where a Task can’t be returned.

However, async void does have some other uses. Take, for example, these two code snippets:

If you’ve ever tried to write XAML which looks like this:

<PasswordBox Password="{Binding Password}"/>

You’ll have quickly found out that:

A ‘Binding’ cannot be set on the ‘Password’ property of type ‘PasswordBox’. A ‘Binding’ can only be set on a DependencyProperty of a DependencyObject.

Here’s something I see from time to time: people new to Tasks in C# don’t know how to cancel them. Let’s look at some common misconceptions, and what you should actually do.

A while back, I found myself wanting to convert the endianness of an integer or floating-point number in C# (for a binary-to-C#-class conversion library that’s still waiting to be finished). Since then, I’ve had a few people ask the same question (normally because they’re reading or writing some low-level format using a BinaryReader or BinaryWriter), so thought I’d write up what I found.

A while back, I had a project which needed to be able to write PuTTY private key files. (For context, it was a tool that was able to spin up Amazon EC2 instances, then launch PuTTY to connect to them, so it needed to turn an RSA key into a private key which could be given to PuTTY). Now, there’s a tool called PuTTYgen which is able to do this, but I needed I needed to be able to do it programmatically.

The other day a few people reported an issue with one of my open source applications, in that a forced shutdown could leave the config file full of zeros. The culprit was almost certainly the fact that the application would try to write to its config file just after the main window was closed (in order to save the window’s size and location), but that write was being cut off after the file had been zero’d, but before some interal cache had been flushed to disk, resulting in lots of NULLs.

So, atomic file writes are in order. Easy on Linux, less easy on Windows. Where to start?

So, I’ve finally got a new website. It’s been a long time coming, but hopefully it’s worth it. This site uses hugo, which is a lovely little static site generator written in Go (which has the advantage of being a single drop-and-run-anywhere executable). The theme’s been adaped from purehugo by Dragos Plesca. The intention is that I’ll record useful stuff I find and figure out on here, relating to whatever programming langauge I’m using at the time.