0

Not sure I have the best title for this question. Feel free to modify it or suggest a change and I will do the edit myself.

I have a standalone executable which wants to maintain a settings.bin file specific to the application. There are two obvious ways to do it:

1. Create/Read the file from the local directory where the executable resides

  • Positive: User can copy the exe and bin file to multiple directories and have multiple versions with different settings.bin files.
  • Negative: I don't want to polute executable directory.

2. Create/Read the file from a "hidden" location like the Local Application Data folder.

  • Positive: Not poluting the executable directory.
  • Negative: The settings.bin file will be shared amoungst any instance of the executable regardless of where it is locaed.

I don't want to do either of these solutions because neither meet both of my requirements, which are:

  • Don't polute the executable directory (IE: don't create a local file).
  • The settings.bin file is different based on the location of the executable.

Any thoughts? I wanted to embed the settings.bin file as a resource but quickly learned you can't write to an embedded resource. I'm all out of ideas.

Michael Mankus
  • 4,628
  • 9
  • 37
  • 63

2 Answers2

1

Use option 2 with a small modification that cancels your negative point (not shared)

You must have something that you can differentiate between exe files.

If all reside in different paths I would do the following:

1) Hash the location of the executable (md5 of the path)

2) Create a directory in the appdata with the hash

3) Store my files there

Else I would try to enumerate myself compared to other processes:

1) When starting check the app data.

2) Attempt to lock a file for writing at:[App Data]\1\sem.oi

3) If that failed attempt to lock a file for writing at:[App Data]\2\sem.oi

Use the settings in the directory that you were able to open the file in

Hope this helps.

Mitzi
  • 2,652
  • 1
  • 20
  • 15
0

Well, you can define your configuration data into the application resource file like a sequence key-value pairs. In this way that information will be embeded into the your binary file, so hopefully you will meet the both of your requeirements.

  • no file created specially for configuration
  • and every file can have it's own built-in configuration, which means you have to made different builds in this case.

What about do not creating a file, but having a flexible configuration on local machine based on the exe path, I think it's hardly possible, if not via some network acess, and some bizzar (in my opinion) architecture.

If you would explain why you have these kind of requirements, may be can give more suitable answer, in case if it's not as is now.

Tigran
  • 61,654
  • 8
  • 86
  • 123
  • The short answer for the requirements is management's requirements and usage senarios. The long answer is that (for requirement 1) management feels the users will be confused by this suddenly appearing bin file and that they won't know what to do with it or what it is. (For requirement 2), for this particular application, it will make sense to have multiple copies of it in mutliple locations with multiple default loading configurations (User will open the exe with the associated configuration he needs). – Michael Mankus Sep 11 '12 at 19:38
  • @michael.mankus: well, you can, based on executable path, generate some (say) *hash* or some unique string and save your conffig file into the named in that way special folder. That folder yuo can save under `ApplicaitonData` hidden directory. – Tigran Sep 11 '12 at 19:46