What triggers "Insert Original Install Disk Title" When Running?

[stanlyn]

Hi,

Many years ago I used Installshield to build a VFP install package. The app itself makes NO references to the registry or to the Installshield installer. I am currently trying to use it in a slightly different way than I originally intended by removing some of the tables. Now when I run the app, something triggers a dialog that asks that I insert the original install media. If I ignore the dialog and NOT close it, it automatically recreates the tables I deleted which is not what I want. If I immediately cancell the dialogs, the program works as I need without the deleted tables.

The question is, what is triggering the dialogs? The executable has no knowledge of Installshield, (unless Installshield modified it) and there are no registry keys used by the app. I do believe that Installshield may have created some keys.

Can anyone shed som light on what might be going on here?

Thanks,
Stanley

 

[DougHennig]

Hi Stanley.

Windows Installer (which InstallShield uses) keeps track of which files are installed by an application and if anything gets corrupted or deleted, prompts you to reinstall. While that's useful for some things, most people find that behavior annoying. That's why most of us have move to other installers like Inno Setup.

Doug

 

[Olaf Doschke]

Hello Doug,

nice to see you drop in again.

Additional to that, as an explanation what happens is not only InstallShield's decision, Installshield simply makes use of Windows Installer Service, which in turn takes care of the repair of lost files. I wonder what really makes it trigger, as there can be any type of files including config you add to the files installing into Program Files folder and the Windows Installer Service does not care for changes of files really, does it?

No matter what exactly triggers which mechanisms, it's time to revisit creating the setup, obviously. First, you should make yourself really comfortable with knowing which system folder is intended for which files. Data should rather go into the AppData system folder, there are some variants here for local AppData, global AppData, or roaming AppData depending on the application type being a single user application, single user but roaming use, or computer related for admin user only, or all computer users etc. These are the details you have to care for if you really intend to make a setup registering things correctly.

A setup never is just over with its initialisation and copying files to their destination, the installer makes entries, so Windows Installer Service also can offer uninstallation, so there is a load of metadata making the Windows System know what to do, which you don't even need to deep dive into. But it pays if you want better control. When you roll your setup you cannot only put all your files into one directory, there are lots of system folders you can choose for the target computer and Installshield plus the Windows Installer on the target system take care of knowing what concrete directory that is on that system with its OS version.

I haven't ever done a setup with Inno, but I think it also makes the setup an official Program Windows knows about and offers for uninstallation in the "Programs and Features" or "Apps and Features" of the Windows control center. That's the whole deal about making a setup, to have all the advantages of having elevated permissions during setup and official system knowledge about your setup files.

So after having said all this, one easy thing to not let Windows repair your database is not installing it via InstallShield files, but perhaps having the necessary CREATE TABLES etc. commands in your application as one function to create a database from scratch in a configurable data directory. VFP has a tool called GENDBC, which does the job to create the necessary code for you instead of making your development database files of the setup. That way the database files never are registered as part of your application to the Windows Installer service and it wouldn't care, if an updated version you later apply has other table files and doesn't need some of the tables of version 1.0 anymore, etc. Just like it doesn't care to repair Word if you delete a DOC or DOCX. Your data really rather compares to documents, it's not part of the application, it's what the user enters and stores for later reporting, statistical analysis etc. So in any database application, you rather have a single database for all data than a document format, though your application might really make use of its capability to create a database at an arbitrary location and let users have several databases instead of single documents. Depends on your application, if that would be helpful to have or not.

As I see Doug here, I also remember he long time ago wrote a blog article when Vista changed rules about data installation into program files here:

http://doughennig.blogspot.com/2007/01/finding-paths-for-special-folders.html

Just read the first few sentences and you know more. This article also shows how to generally find out where your data was installed, if you instructed InstallShield to install to some of the AppData flavor system folders. Today you can be lucky to not need to support XP anymore, so this paradigm change from XP to Vista/W7/W8/W10 doesn't hit you, you can limit to the way to find out system folders since Vista.

Well, or you rather do as I suggested and let the user decide about the data directory and create it as the first run configuration of your application after its setup, so Windows doesn't care for your data. That also means the data remains when a user uninstalls your software, which could be helpful to keep it.

Bye, Olaf.