I've already found this thread, which seems to have ended without resolution.
I have a similar issue. My database component is rather complicated and is handled by a DLL which references support files in a four-level-deep directory tree. I quickly discovered that directory trees can't be done in IS, and worked around it by dropping the files as part of the database component, then deleting them when the DB install or upgrade is complete. Because there are so many files and branches (300+ files), I'm using dynamic linking.
Initial installs work fine. The problem occurs later when a user modifies or repairs the installation. The (deliberately) "missing" database files are noticed and restored, which is not at all what I'm looking for.
Every solution I've thought of so far can be classified as "shameful hack." And so after lurking a while, I turn to the community to find out: what is the correct way to deal with install support files which must be in a nested directory tree? Is there a way for me to tell IS/MSI that certain files need not ever be repaired, that they are in effect temporary?
Caveat: redesign of the DB install/upgrade components is not an option.
Actually I have the same problem. One solution is to get your dll to create a backup file from the database, and then restore this backup onto the target database.
In the meantime is there an Installshield engineer that can tell us how to install a specific folder/file structure in the "Support Files" node without using a self extracting zip or the like?
For example, be able to create folders as well as insert files into the "Support Files" node.
I'm also in the exact same situation as the original poster and would really like to know what the best practice for dealing with this is. I can't imagine that it's an uncommon scenario; some way of dynamically linking support files seems like an obvious and useful feature that InstallShield doesn't seem to have an answer for. So what do other people do to get around this?
