I encountered a very curious issue today, as a user of one of my tools complained that the tool was crashing because of an access to an uninitialized field. Because of the error reporting system in all my tools that gives the user the stack trace to pass on to me, I saw that the line that was causing the crash was a GetValue() on a registry key and value, that the user insisted existed. So, looking around StackOverflow, I noticed that if you compile to x86, you may have issues accessing some keys and values in the registry, because Windows may give you the wrong Registry view by default (I guess Windows gives a different view to 32-bit applications that the one it gives to 64-bit ones). I was accessing the keys by using OpenSubKey() on Registry.CurrentUser, but I guess that gives me whatever registry view Windows wants to give me.
So, given that there’s two RegistryViews, I thought I should change my GetRegistrySetting() and SetRegistrySetting() code to try both. Once I did, the problem was gone. Read on for the code that is part of my LeftosCommonLibrary set of tools, or just view the file that contains the code below in GitHub.
For quite some time, my update notification mechanism for most of my projects consisted of a Web Client async request to download a version file, check it against the current version, and show a message that would lead the user to a download page. This is all simple and great, but if you’re like me and you release updates constantly, you’d be better off using a delta updater, that knows which files have been updated since the last release, downloads them and installs them. For NBA Stats Tracker, I’ve taken the middle road. I release new versions quite frequently, so getting the user to the download page, then using the download link, then going through all the steps of installing it could be a hassle, deterring them from downloading and thus using the latest version. I thought I’d make the update process just a few clicks and minimize the time it requires to update to a few seconds.
Here’s how it works.
UPDATE: The post has been updated since first being published with some improvements to the code.
UPDATE #2 (May 15, 2013): The post has been updated again with much cleaner code and additional functionality.
To err is human. And so, many (well, hopefully, not that many) times your programs may crash. And most of the time, they won’t crash inside your development environment, hooked to a debugger that will give you all the information you need on why and where the error happened. They’ll crash on your client’s machine. So, what can you do if you’re developing a WPF application, and want your program to produce nice, detailed error reports that the users can send to you?
It’s quite easy, actually.