Sometimes, adding default settings will result in your program throwing a generic error in the app.config file. The MSDN reference page for the error says something like, “This is a generic error thrown when something goes wrong.” Wonderful?it’s completely accurate and totally useless. No surprise there…

Well maybe now there is some hope: here’s how to fix at least one of these settings problems. There may be a couple of different outer messages that mask it, but this error is always thrown on a Property Get block for one of your settings, and the inner error is always a failure to initiate.

What has actually happened is that the format of the saved settings does not match the format the program currently expects, so it cannot read them. You need to get rid of the old settings. The problem is that they’re tricky to find. They are not anywhere near your development environment. You will find them hiding in a special folder that holds settings for most Windows programs. It should be something like:

C:Documents and Settings*yourname*Local SettingsApplication Data*yourproject**yourprojectid*(*yourversionnumber* 

Inside the final folder, hidden like a diamond in a coalmine, is the culprit, a file called simply user-config.

Now that you found the user-config file, it is time to surgically remove it.

*** DO NOT DELETE IT *** DO NOT DELETE IT ***

It may not be the problem, and it would be a shame to throw away your data for no reason. It would be even more of a shame if you were accidentally looking at the wrong user-config file. Instead, rename it so that VB cannot see it. I usually put an “x” in front of the current name. Don’t worry. The default values you entered into settings are stored elsewhere and will remain intact.

Now retest your project. Hopefully, now you are up and running again. If this file was the problem, the project should now run normally.

When you look back into this folder, you will see that a new user-config file has been created. You will, however, have lost any changes you made to the program while you were testing. Should you need to remind yourself what these changes were, the old file (the one that you cunningly did not delete) is readable by NotePad, and once you get past the long data names and strange routines, you can pretty much guess what is going on.

Here are some things to remember:

• Surprisingly, once the program runs successfully, hiding the new file and putting the old, corrupt one back does not recreate the problem. I have no idea why.
• The mid-level folders are hidden/read-only so make sure Windows Explorer is set to be able to display them as you drill down.
• *yourprojectid* looks like gibberish. It starts with *yourproject*, then .vshost.exe followed by a bunch of weird characters.