Handling Corrupt user.config Settings

Introduction

The Settings class has been with us since .NET 2.0, and is still the simplest and preferred way of storing user settings for your application. However, there is a lingering issue with the Settings mechanism that has yet to be satisfactorily resolved by Microsoft.

Furthermore, it took me quite a while before I actually discovered a solution. Luckily, the result ended up being quite a bit easier than some of my attempts, and although I couldn't find it mentioned anywhere in my searches, I stumbled upon it while debugging one day.

In fact, it turned out to be so simple in retrospect that many of you may have already solved this and thought nothing more of it, but since it took me a while before I realized the solution (and indeed that there was a problem to begin with), I thought others might benefit from having it explicitly laid out.

So, without further ado, here's the problem and solution.

The Problem

The problem is this: if the user.config file gets corrupted (which has happened to me on more than one occasion, entirely on its own), there is seemingly no way to recover from this programmatically, and your program will crash the moment Settings is accessed, every time it is run. What's worse, we can't even call Settings.Default.Reset(), because that method just throws the same exception. Up until now, the only option I had was to instruct users to manually delete their user.config file by rooting through the various hidden settings folders in their user account. This is not something the novice user will appreciate having to do.

What makes this so difficult is the fact that the actual location of the user.config file is so convoluted as to be impossible to determine by hand. For example, here is the path to my OrangeNote user settings file:

C:\Users\Logan\AppData\Local\The_Little_Software_Compa\
  OrangeNote.exe_Url_wxcnyrmstqy3oj1qwckdjq3gjqkq4fel\1.0.0.0\user.config

I don't know about you, but that hash code in there scares the pants off of me, and I don't like the idea of having to figure that out myself. The path will also change depending on whether the assembly is signed with a strong name or not, and other factors like the current version, executable name, company name, etc. Since hard-coding any kind of algorithm would be a pain and would introduce a great many dependencies and therefore potential failure points, I don't consider that an option.

The Solution

Obviously, the solution is to either repair or simply delete the user.config file, but we have to find it before we can do that. I won't get into repairing, since there's no simple way that I know of to do this. In most cases, deleting the user's application settings, while inconvenient, is not the end of the world, so long as the user is given fair warning that this is about to happen. You're free to take other measures, of course.

It turns out, the path to the user.config file was in the exception all along! But, it's sneakily hidden inside an InnerException, and maybe this is why it eluded me at first. So, allow me to present a block of code that will basically handle this occurrence in a universal manner. You should place this block somewhere near the beginning of your application startup, before any call to Settings is made:

try {
    Settings.Default.Reload();
} catch ( ConfigurationErrorsException ex ) { //(requires System.Configuration)
    string filename = ( (ConfigurationErrorsException)ex.InnerException ).Filename;

    if ( MessageBox.Show( "<ProgramName> has detected that your" + 
                          " user settings file has become corrupted. " +
                          "This may be due to a crash or improper exiting" + 
                          " of the program. <ProgramName> must reset your " +
                          "user settings in order to continue.\n\nClick" + 
                          " Yes to reset your user settings and continue.\n\n" +
                          "Click No if you wish to attempt manual repair" + 
                          " or to rescue information before proceeding.",
                          "Corrupt user settings", 
                          MessageBoxButton.YesNo, 
                          MessageBoxImage.Error ) == MessageBoxResult.Yes ) {
        File.Delete( filename );
        Settings.Default.Reload();
        // you could optionally restart the app instead
    } else
        Process.GetCurrentProcess().Kill();
        // avoid the inevitable crash
}

You will need to add a reference to System.Configuration in order to use the ConfigurationErrorsException type. The above code uses the WPF version of MessageBox; you will have to tweak it if you are using Windows Forms.

Trying it Out

To try it out, all you need to do is open your valid user.config file in a text editor and make some change that the parsing engine won't like, such as adding some data to the root, or deleting a closing tag. Then, just launch your application, and you should now receive the appropriate warning.

Points of Interest

If anyone has any alternative solutions, don't hesitate to share them!

History

• Oct. 17, 2008 - First published.