Shortcuts changing the relative path?

Question

I have used Flexera's Installshield and it has seemed to work for the most part except the shortcuts it placed in the start menu and on the desktop.

The issue arises when the program starts and returns an error with opening the sqlite database file.

The issue is fixed by running the actual .exe from the program files folder, and if I create a manual shortcut.

I have noticed that the automatic shortcuts they have a target of what the manual shortcut has for a target location.

Any ideas?

Answer 1

I am not in a position to propose a direct solution for your specific problem. On the other hand, I have had some paths/relative-reference problems in the past when working with different Windows installer packages which I solved by running a program passing all the required information to the installer.

Example of what I mean:

1. A small program is executed right before starting the installation. It retrieves all the required information (e.g., desktop's path) and writes it to a temporary location (e.g., Windows Registry).

2. The main installation package is started, reads/deletes the information from the temporary location and brings it into account while performing the installation (e.g., path for the shortcuts).

Depending upon the available setup options, you might perform the aforementioned actions in different ways. The simplest alternative I see is: creating an .exe file (install.exe), only one to be executed by the user; it will be in charge of retrieving all the required information, writing it to the temporary location and calling the main package (\installation files\setup.msi). Right after being started, the installation package will read the information from the corresponding temporary locations, delete them and bring this information into account while performing the corresponding actions (setting up the shortcuts).

The main reason why I prefer to rely on this kind of configurations (preliminary .exe calling the main package or script/.exe being called by the installation package as the first action) is because it offers a high flexibility. It does not only accont for eventual problems/incompatibilities from the installation software, but also sets up a framework allowing me to perform more complex actions (e.g., security system) whose implemention is much easier by relying on the corresponding programming language (C# in this case).