views:

72

answers:

2

I currently store a serialized XML file in the application directory that contains all changes specific to the program operation (not typical system or user configuration). Weeks ago, we started running into problems where it would not save correctly (read my previous question about this).

Long story short, we finally discovered that Windows 7 (and sometimes Vista) has an issue with writing into the application directory (specifically anything under Program Files). Now, if this were a normal configuration file I would simply store it under the user's APPDATA folder, but it is not normal. We run this on our own instrumentation, and misconfigurations are 99% of the reason customers have issues running our software. So we need this file to be accessible such that they can easily find it and email it to us. Appdata is hard enough for experienced users to find, much less very non-technological people.

We've also tried running it as Administrator, and making folder permissions wide open (we have control over every computer it runs on; it will never run on some random person's machine). But, these sometimes work, and sometimes do not.

The worst part is that when I write the file back out, it doesn't even throw an error; it simply writes it to some temporary directory that expires at some unknown point in time. Weeks later, our user will have an issue, and the configuration file is all messed up.

So, my question is where should I be storing this file, if not in Program Files? Should I just put it in APPDATA anyway, and make a small utility that emails it to us automatically in case of a problem? Or can I leave it in Program Files, but change some specific permission or registry key to allow it to operate normally?

+1  A: 

It depends on whether or not the user needs to edit the file directly. If not, you should put them in %APPDATA%, which you can access via:

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)

Otherwise, you might put it in My Documents:

Environment.GetFolderPath(Environment.SpecialFolder.MyDocuments)

Either way, putting it in Program Files is not a good idea. As you discovered, there are permission issues, even if running as Administrator.

Mike Caron
The user will indeed need to occasionally edit it directly. I did not even think of putting it into My Documents... Normally this would be an absurd idea, but since these computers are controlled by us, this will be a perfectly acceptable solution.
drharris
+1  A: 

For those users, you could build a button in that would open this directory. You could put it in an inconspicuous place that you could later direct them to.

For users that have an email client on their box, you could have a button that would create a new email with subject and automatically attach the file to the email.

MCain