This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- How to avoid executing setup.exe twice at the same time
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 21, 2017
07:54 AM
How to avoid executing setup.exe twice at the same time
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.
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.
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 22, 2017
09:47 AM
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
Chad
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 09, 2017
03:08 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jun 09, 2017
03:12 PM
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. 😃
![](/skins/images/CC38E504FC9E1309DC48ACFEB4925670/responsive_peak/images/icon_anonymous_message.png)