How to avoid executing setup.exe twice at the same time

[posix99]

The problem: It is possible to run setup.exe twice. Which makes the 2nd execution display a message "unable to save file" "the process cannot access the file because it is being used by another process".

The intention of a possible solution would be to display a message like "Installation is already running" and gracefully exit/end the 2nd setup.exe execution.

I already tried thinking of using a mutex, or an Is(FILE_LOCKED, "FILE PATH") function. But both are referring to the bundled .msi that setup.exe extracts.
I am looking of a way to block this at the setup.exe

The project type is a simple msi.

[chad_petersen]

The Setup.exe is controlled by InstallShield. You can only control it indirectly by using setting in InstallShield - No setting to establish a mutex and no way to check for an existing copy in memory since you'd have to modify the Setup.exe itself - which you cannot.

Chad

[Cary_R]

you'd have to modify the Setup.exe itself - which you cannot.

Sort of true.

There's extensibility built into setup.exe in the form of prerequisites. One could write an *.exe whose single purpose in life was to check a mutex or lock, and then pass back an error return code if found (which would error out setup.exe). You'd just call this as a silent prerequisite without any conditions so it always runs, and this gets you halfway there.

The other half is implementing the lock, which you'd have to make sure takes place during the lifetime of the install. That's a little harder, but my first thought would be to use an Asynchronous custom action which is written to:

1. Grab the mutex (we'll call it _OurMutex for simplicity)
2. Wait for the _MsiExecute mutex to be locked (this happens during the Execute sequence)
3. Wait for the _MsiExecute mutex to be released
4. After which point, you can release _OurMutex because the install is effectively over after the exec sequence has run.

[Cary_R]

Cary R wrote:
Sort of true.

There's extensibility built into setup.exe in the form of prerequisites. One could write an *.exe whose single purpose in life was to check a mutex or lock, and then pass back an error return code if found (which would error out setup.exe). You'd just call this as a silent prerequisite without any conditions so it always runs, and this gets you halfway there.

The other half is implementing the lock, which you'd have to make sure takes place during the lifetime of the install. That's a little harder, but my first thought would be to use an Asynchronous custom action which is written to:

1. Grab the mutex (we'll call it _OurMutex for simplicity)
2. Wait for the _MsiExecute mutex to be locked (this happens during the Execute sequence)
3. Wait for the _MsiExecute mutex to be released
4. After which point, you can release _OurMutex because the install is effectively over after the exec sequence has run.

This of course presumes that you can get the prerequisite to fire off before the *.msi is cached to the location it shows the error on. Maybe create a dummy *.exe which always passes back an error code to test that first before writing the rest of it. 😃