Preserve INI Install

[hooovahh]

Hello all.  I have an application.  This application has an installer.  During the install the EXE and the INI file are installed and the EXE uses the INI and can then write to the INI any settings changed in the application.  If I have a new version of the application I make a new version of the installer.  The problem (if it is one) is that during the install the new INI will replace the old one and all of the old settings will be lost.

 

On the one side this is a good thing.  This means that when version 2.0 is installed it comes with an INI file that is compatible with the 2.0 of the EXE and will have known good settings.  On the other side this means that if there were any custom settings they will be lost.  It is possible to run a EXE after an install, so I was thinking one possible solution could be to backup the old INI (sometime before deleting it) then after the install compare the two and any keys and sections that exist in the old and new INI, to be copied so the new INI has the same settings as the old.

 

Any thoughts on this?  Is this a non-issue and installing a new EXE with the new INI is the way to go, with the understanding that old INI settings will be lost?  Thanks.

[Darin]

I have run across whacky users who do things like delete .ini files.  What I have taken to doing is not installing the .ini file but recreating the default one within the program when it can not find one.  This can be as simple as keeping the default ini file inside a string constant, or if I have a configuration page I just save the default configuration as if the user had changed nothing from the default values.

 

Along these lines, I can also detect an ini file from a previous version.  In this case I can provide mutation code to update some values, and toss others.  I do this inside the app, interesting thought to make it part of the installer, but I guess you only have one shot at mutation that way.  Again I have seen (and perpetrated)  copying of an old ini file after installing an app, and that is why I chose to make it part of the app.

 

NI does something like this to you (each year a new version with a new ini file).  How do you like it?  I usually copy and hope nothing blows up.

[bmoyer]

What I do is I look for an ini file for my application in the COMMON_APPDATA folder (for Win 7 it's usually C:ProgramData<CompanyName><ApplicationName>) and if the file is not found, to copy it from the location of the exe to this location.  That way, if they make changes to the default configuration, the changes are stored in the AppData folder.  In the VI that reads the .ini, I have a the default settings stored, and if I happen to make a new setting or section, the new settings are created automatically in their copy of the ini but they get to keep all of their previous settings.  I use the OpenG Variant Configuration libraries to handle creating ini's from clusters.  Attached is a simple example.

 

Bruce

ini example.zip

Edited February 21, 2013 by bmoyer

[ShaunR]

Nowadays I use a DB file for settings which means you can mutate from version to version with a single, non application specific, query and do other stuff like revert to defaults without having to write application specific code. I'm also leaning further towards having a single "config" DB file for all applications which works great especially if you have multiple applications (it's like using the windows registry, but works on all platforms and you can copy it!).

 

You can do something similar with INI files and have global INI directory somewhere outside your applications (as bmoyer is suggesting) which has a sub-directory structure with the app name and version. Loading and saving is just a matter of building a path using the App name and version (i.e. non-application specific). This doesn't get around mutation, but it means that if you un-install or re-install you can always get to the same point as you, in effect, build up a history even if they delete the entire application directory.

[mje]

I agree with the general trend: handle your ini stuff in the application bot the installer. Mutate of create it when needed. A side effect though is all of my apps leave configuration data in profile folders since the uninstaller never checks for what the app has left behind.

[hooovahh]

What I'm doing right now can be considered non-standard.  The INI and EXE go into the Program Files folder, and the INI has been "unlocked" by the NI installer.  This makes it so anyone on the system has permission to write to it (but no other files).  I've known for a while that files under Program Files should not be changed after the installer because of user permissions issues and that the ProgramData is the correct place for this information.  To be more standard moving forward I think it would be a good idea to try what bmoyer suggested.  I can have the installer install into Program Files the EXE and INI and keep them locked to read-only.  Then settings are read from the ProgramData first.  If the file doesn't exist (or there is an error in reading the Section/Key) use the INI file in the Program Files.  Then when making changes save to ProgramData.

 

An added benefit I didn't think about with this approach is I can have a "Reset to Default" button that will simply delete the ProgramData INI file, causing the software to use the Program Files INI for settings.

[bmoyer]

Then when making changes save to ProgramData.

 

Win 7 has some unexpected rules when it comes to the ProgramData folder, you can create and modify files (and folders) but if you switch users, they only have read access.  So for this I have my installer create the folder where I will be storing the modified ini (by creating a new destination [Public App Data]<Company Name><Application Name>), and set the folder to unlocked.

[hooovahh]

Win 7 has some unexpected rules when it comes to the ProgramData folder, you can create and modify files (and folders) but if you switch users, they only have read access.  So for this I have my installer create the folder where I will be storing the modified ini (by creating a new destination [Public App Data]<Company Name><Application Name>), and set the folder to unlocked.

Awesome idea.  Yeah I was thinking about how all of this would work when switching users as well.  I have not run into this myself but apparently there is a bug with 2012 with the unlock that doesn't work properly.  Sounds like it is planned to be fixed in the next release

[bmoyer]

Thanks, I was not aware of that bug (but I'm not using 2012 much yet anyway).  Post 18 on that thread says there's a workaround, but I'm not sure what it exactly means.

 

 

Also, in the meantime, if you unlock a folder, try changing the default install dir such that unlocked folders are not relative to the default install dir as a temporary workaround.

 

Anyway, I'll wait for the update.

[mgunning]

Interesting thread, I was pondering over the same issues a few weeks ago. What I ended up doing was pretty much the same as bmoyer i.e. have the application copy the ini file over to a folder in the "C:ProgramData" folder.

I didn't know about the 'unlock' switch in the installer, so to get around the user access issues I was using the "icacls" command to set the user permissions. When the ini file is first created under ProgramData, I feed the command "cmd /c icacls "<path to ini file>" /grant BUILTINUsers:(F) /t" to "system exec.vi". This assigns all users full access to the ini file.

This works fine as far as I can tell, but I'm a bit nervous about using commands I don't really understand, so I might switch to the 'unlock' folder method instead when the issue with LV2012 is fixed.

[hooovahh]

I didn't know about the 'unlock' switch in the installer, so to get around the user access issues I was using the "icacls" command to set the user permissions. When the ini file is first created under ProgramData, I feed the command "cmd /c icacls "<path to ini file>" /grant BUILTINUsers:(F) /t" to "system exec.vi". This assigns all users full access to the ini file.

This works fine as far as I can tell, but I'm a bit nervous about using commands I don't really understand, so I might switch to the 'unlock' folder method instead when the issue with LV2012 is fixed.

I've used icacls before for setting permission as well (before I knew about the unlock feature).  What I did then was install like normal, and then I needed to remember to run the batch file to change INI permissions after the install.  Unlock removes this extra step but again will simply overwrite the INI during the install (which is where this topic came from in the first place)

[bmoyer]

Unlock removes this extra step but again will simply overwrite the INI during the install (which is where this topic came from in the first place)

The installer doesn't put the ini into the [Public App Data]<Company Name><Application Name> folder, it just creates the folder and unlocks it.  If the folder already exists, then nothing happens and your custom ini file remains intact.  The default ini that is with the exe is overwritten, but since the ini already exists in the App Data folder, the ini with the exe is not used.

[hooovahh]

The installer doesn't put the ini into the [Public App Data]<Company Name><Application Name> folder, it just creates the folder and unlocks it.  If the folder already exists, then nothing happens and your custom ini file remains intact.  The default ini that is with the exe is overwritten, but since the ini already exists in the App Data folder, the ini with the exe is not used.

I wasn't talking about the App Data folder, I was talking about normal NI installers and how standard operation is for now with applications I make.  I was saying that normally someone would need to change the permissions on the INI file in the Program Files folder if the application is going to Read/Write it.  This was done using the command line program icacls but using the "unlock" on that INI file removes the extra step of having to run icacls but will still overwrite the INI (in Program Files)

 

I understand how you handle INI settings and I will try to use something similar in the future after some initial testing.

[Phillip Brooks]

Jim wrote this blog post some time ago on his old blog about multiple versions of a file format.

 

Supporting Multiple Versions of a File Format

 

Darin's description seems similar to Jim's method where the application mutates the contents for the user.

Edited February 26, 2013 by Phillip Brooks