Writing over support files while installing my custom application

[LVKevin]

Hello,

I have written my custom application in LabVIEW and created an installer using App Builder. I have support files (ini files) that should be installed during the installation. The files may or may not already exist on the target system (for example I may want to overwrite C:\TestStand\cfg\Users.ini). What I have found so far is that the installer will copy the files to their proper destination *IF* the file does not exist previously. If the file does exist then the installer will not delete it and copy the new file in place. I look for options in the app builder to ensure old files are deleted and found nothing...Does anyone have any suggestions?

Thanks,

Kevin

[Labviewguru]

Kevin,

This is a common problem when distributing applications (at least it has been for me.)

I have found the National Instruments Application Builder installer to be woefully inadequate, and have come to use outside applications, or custom installers instead.

If you have the resources, I strongly recommend InstallShield Express. It's not that expensive (compared to LabVIEW) and has tons of features including features to accomplish what you need.

Otherwise, I would suggest that you create your own installation program in LabVIEW, or as a DOS Batch file. Neither of these are as professional looking as a canned installer such as Install Shield, but they are free, except for the time it takes to write them.

[Klaus_M]

Does this problem still exist in LV2009 and later?

I did not find a solution except calling a batch file containing xcopy commands, called by the installer:

Build Installer - Properties - Advanced - run executable at end of installation.

A rather old fashioned method!

Thanks for any hints

Klaus

[FredCirr]

+1 Even a few years later. Using 2016 I'm struggling to find a solution to this issue. The post-build actions doesn't help either since the installer has already decided not to replace the files by then.

Have anyone found a nice solution for this yet?

[RavensFan]

I haven't had to work with this, but here are my thoughts from the outside looking in on how to do it.

What if the configuration files were given another name from the usual?  Then on a post install action, the program deletes the existing files and renames the new replacements back to the original name?

[wiebe@CARYA]

---

@FredCirr wrote:

Have anyone found a nice solution for this yet?

No matter what the installer does (replace the ini files or it keep the originals) it will offend someone.

So a DIY solution based on a per project basis seems like the only solution to me.

For instance... The program starts. Check if there is a fresh installer ini file. If so, copy\merge\replace with modified ini file and save it as a modified ini file. Delete the installer ini file. Next time it won't be there, so use the modified ini file. You'd need some scheme to tell the application what to do with keys: delete it, modify it, add it, etc...

[FredCirr]

For our issues, setting the source file settings for the specific files to "Vital" did the trick. 

[croohcifer]

Changing the source file setting to "Vital" didn't fix this for me.  Nor do I think it should since, according to the help, "Vital" is not a "force overwrite".  It just means that the installation will fail if the file fails to install.  When I make my INI "vital", the installation runs and still doesn't overwrite the INI file.  I ended up using an NI Package to install the INI file.  Packages have their own set of issues, but at least this wasn't one of them.