chamberlain
17th December 2008 12:16 UTC

Running installed executable on a new process thread
Hi All,

I have an installer which calls the installer for MySQL 5.1. Once the MySQL and our installer have finished, the final wizard page allows the user to start our application.

The problem is that our application is not given the true environment variables from Windows, only the environment variables that were present when the installer started (it is created as a child process). During this time, the MySQL installer may or may not have altered the environment variables. Our application reports an error which disappears if you exit the application and start it again (so that it takes the current environment variables).

Is there a clean way of starting our installer application in a truly new process from Windows at the end of our installer? Or is there a way for child processes to get the current environment variables and not a copy from the main installer process?

kichik
17th December 2008 20:25 UTC

There probably is a way to do it, maybe by running explorer.exe and having it run the application for you, but I don't know of one. What I'm sure will work is manually setting those environment variables by calling SetEnvironmentVariable. That would require you to know exactly which variables are set.

chamberlain
18th December 2008 07:25 UTC

Thanks for the reply kichik.

The problem with using SetEnvironmentVariable is that I would need to know the value of the install directory of MySQL, which the user can always change via the MySQL installer.

What I could do is put in a check to see if MySQL is installed to the default location. If it is, then I can call SetEnvironmentVariable and then allow the user to start the executable at the end of installation. If it is not present in the default location, then perhaps I can disable/hide the start option on the final page, or even replace it with a "reboot required" message.

kichik
19th December 2008 07:55 UTC

Doesn't MySQL write that value somewhere in the registry as well? At the very minimum, environment variables are written to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment.

chamberlain
19th December 2008 08:43 UTC

Good point! I am not sure whether that registry variable will contain the updated value from MySQL, but I will investigate it as that would be a cleaner solution to just pass the updated path to the sub process.

That way, our installer does not need to know about sub-installers in case we add or remove them in the future.

I will test this solution.

chamberlain
19th December 2008 10:37 UTC

Ok, I tried that and it would have worked, if weren't for the fact that the separate MySQL installer we have runs the MySQL configuration wizard as a sub-process.

This means it tries to pass an updated PATH variable to our application which has not yet been updated.

To get around this problem, I have disabled the "Start application" option from the final wizard page. We have several different versions of the installer (standard, full and express) and this issue only affects the full version where the user has complete control of the MySQL installer. This means that we can never guarantee that the user configures MySQL correctly and consequently cannot guarantee that the "start application" option will work.

For our other installers this isn't a problem as MySQL either exists already on the end system, or we have control of the MySQL installer.

Many thanks for the tips kichik!