Building a text file into an exe (not the support directory)

[BertMcMahan]

I have a config file that I'd like to have included with my application. Adding that file to the build specification and including it with the build is straightforward; that's not my question.

My question is this: What happens if the user deletes the config file? In the past I've handled this by looking for the file, and if it doesn't exist, create it with some default values stored in a global variable* or VI or whatever. This works, but it means I have my default settings stored in an unweildy giant VI or global variable. I'd rather create a default config file that gets included at compile time but that is non-deletable by the end user.

Now, this may not make any sense, but is it possible to store a "backup" default config file within the executable itself? That way, if it's not detected, the exe can copy the backup one from... "inside itself"... into the proper directory. That would save a decent amount of time and effort when I need to update my config file. I can make it happen storing my default values in a constant somewhere, but it gets unweildy after a while. I'd prefer to automate it if possible.

Any ideas? I've tried adding a text file to a project and setting its Build Destination as my Application.exe but that option is grayed out.

*global variable- I'm not talking about using a Global as my working internal variable, I just mean using it as a place to store default settings. It would only be edited at compile time, and never read or used in any programs unless it was used for creating a new default file.

[tyk007]

In theory yes you can though there is no built-in support or assistance for such a feature as far as I know. My first reaction to solving this would be:

1. Create the config file with your defaults and store it on disk. Include it in your build so that it is an artifact, as you have now.
2. Create a Pre-build VI for your Build Spec that reads the config file contents and stores it into a Global VI, making that the default value of the VI. The easiest way to do that is with VI Server calls by opening a reference to the Global VI, writing data to the control, then setting the current values as default. The advantage to using a Pre-Build VI is that if you update your "defaults" later you don't need to remember to update the Global content.
3. Your application, at run-time, can validate the on-disk configuration file and, if it is deemed inappropriate, can simply read the contents of the global and save them back to disk, over-writing the current config file.

It requires a bit of infrastructure to setup (and documentation to communicate to other devs later) but could be worth the investment if you think the "risk" is high enough.

[Gregory]

Lately, I've been using the MGI Read/Write Anything VIs to read and write a configuration cluster to the file. If you have a cluster with your config data in it, you could create a constant and use that in the case that the file is not found.

However, why do you have to worry about whether or not certain dependencies have been deleted? Can you find out who is deleting stuff and tell them to stop it? What if they delete a .dll or the executable itself?

[BertMcMahan]

I'm actually using XML files right now, which work similarly to MGI's functions but that support Objects, which is what I've been using to store my config parameters.

I don't actually have a problem with users deleting these specific files- I'm just hoping to save a day-long trip to a customer site to figure out he just screwed up his config file accidentally. (I had a customer once where I was called in to fix their system that had been down for days by someone who accidentally screwed up their config file!)

This software is going to an outside customer, so I won't be available to troubleshoot and this is a fairly easy thing to patch.

I think for now I'll add a sneaky secondary backup config file in ProgramFiles, and have the main everyday-use config file stored in Application Data or something. If the one in Application Data isn't there, it'll revert to ProgramFiles. If the one in ProgramFiles isn't there, well, they get to reinstall their program.

[RTSLVU]

---

@BertMcMahan wrote:

I think for now I'll add a sneaky secondary backup config file in ProgramFiles, and have the main everyday-use config file stored in Application Data or something. If the one in Application Data isn't there, it'll revert to ProgramFiles. If the one in ProgramFiles isn't there, well, they get to reinstall their program.

---

How about just making a backup copy of the current config file each time the program successfully launches and hiding it in the Temp directory?

Then if the program is started and the config is missing or corrupted restore it from the last good backup.

If that is gone then make them reinstall. 

[wiebe@CARYA]

Don't give the user the rights needed to delete files in the (program files) directory.

This is one reason why windows has a user management system, although nobody seems to use it or seems to know how to use it... Everyone's an admin. Very convenient for viruses as well.

[BertMcMahan]

Unfortunately I'm deploying onto a system I have no control over 😕 If this was an in-house thing or if I was supplying the computer things would be different. In this instance the ONLY thing I have absolute control over is the exe itself, so I was hoping to have a secret hidden file inside just for the sake of extra bulletproofness.

[pauldavey]

Can you just have a string constant on your block diagram with the default config file contents? If the file doesn't exist, write it out again.

[wiebe@CARYA]

Most functions\libraries to read from an ini file will return the default value if it's not there. So the default will be returned if the file is not there. You will get an error when you open the file, but if you ignore that, you have a valid empty file, and all the hard coded values will be used.

That would effectively provide the exact same functionality as a file\string\whatever backup of the values. And you get default values when the user deletes just one key or section, not the entire file.

My solution would be to say "don't delete the file. If you do, I will charge money to fix it". But then that won't work for every customer.

[BertMcMahan]

That indeed is the way I've done it in the past. I have a global variable I use that I set up during edit time and never write to at run time, then if my ini files don't see the value they check the global. My struggle was that I was hoping to be able to pile all of my default values up into a config file instead of storing them as default values inside a global.

I like the idea of using scripting to accomplish the same thing as a pre-build action. It's a couple of extra steps but it's not too bad.

I tend to hate having "magic numbers" in my code (like hard coded default values) and would prefer to keep all of that in a human-readable file somewhere.

And I like the "I'll charge you money if you delete this file" approach. Right now I'm planning on a popup that basically says "Look, the file was gone- open the config window and try to fix it before continuing." That way the customer can at least TRY to fix things and won't feel beholden to an angry popup.

Now if we could get actual access controls now THAT would be a wonderful thing 🙂