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
- :
- Custom Action after Reboot
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
Aug 08, 2012
09:28 AM
Custom Action after Reboot
I have an interesting problem.
Here is the long version - I have put the short version below:
I have developed an application, which needs to be registered against another third party application during installation. I am developing the installation as a Basic MSI project.
To solve the regiostration problem, I have created a custom action, which calls MyApplication.exe with /regserver. Since the exe I call is installed with the application, I have made the custom action's in-script execution 'Deferred in System Context'. It executes just before InstallFinalize. I cannot use any of the installshield build-in ways of registering assemblis, due to carious issue, which I won't trouble you with here - it is enough to state that I need to make it as a custom action.
Besides deploying my files, my installation also includes several microsoft Merge modules (like Visual C++ 10.0 CRT etc.). Lastly, the MSI is part of a chained installation. The MSI is launced from a parent MSI.
Now - to the problem itself.
The Third party application, which I am registering against, is also using some of these Microsoft Merge Modules - but an older version of them. This means, that my installation wants to update the merge module, and therefore the restart manager pops up and wants to stop my thirdpart-applications service. If I chose to stop it, my installation fails, when I get to my custom action (the registration can't be made without the service. If I chose to just continiue, the installation completes just fine.
On an XP however, I don't have the restart manager to detect that the file is in use, and therefore my installation just flat out fails.
So - what to do?
I have a few ideas, but I am in doubt what would be the smartest, and I hope you will be able to assist.
I am thinking - if I in some way can postpone the custom action untill after a reboot, if I can detect that the merge modules will be in use (both with and without the restart manager). Bot how to accomplish that, I do not know.
The short version, this is what I want:
- Detect if any of the Merge Modules (or older versions), which I am about to install, are in use (without using the Restart manager, sicne I need to support Win XP)
- If no, then just continiue, and do my registration at the end of the installation.
- if yes, then schedule the registration to happen after a reboot, and put said reboot in the end of the installation (do note, that my MSI is part of a chain, and is therefore launched from a parent-msi)
Any help to accomplishing this, is much appreciated
Thanks in advance
Here is the long version - I have put the short version below:
I have developed an application, which needs to be registered against another third party application during installation. I am developing the installation as a Basic MSI project.
To solve the regiostration problem, I have created a custom action, which calls MyApplication.exe with /regserver. Since the exe I call is installed with the application, I have made the custom action's in-script execution 'Deferred in System Context'. It executes just before InstallFinalize. I cannot use any of the installshield build-in ways of registering assemblis, due to carious issue, which I won't trouble you with here - it is enough to state that I need to make it as a custom action.
Besides deploying my files, my installation also includes several microsoft Merge modules (like Visual C++ 10.0 CRT etc.). Lastly, the MSI is part of a chained installation. The MSI is launced from a parent MSI.
Now - to the problem itself.
The Third party application, which I am registering against, is also using some of these Microsoft Merge Modules - but an older version of them. This means, that my installation wants to update the merge module, and therefore the restart manager pops up and wants to stop my thirdpart-applications service. If I chose to stop it, my installation fails, when I get to my custom action (the registration can't be made without the service. If I chose to just continiue, the installation completes just fine.
On an XP however, I don't have the restart manager to detect that the file is in use, and therefore my installation just flat out fails.
So - what to do?
I have a few ideas, but I am in doubt what would be the smartest, and I hope you will be able to assist.
I am thinking - if I in some way can postpone the custom action untill after a reboot, if I can detect that the merge modules will be in use (both with and without the restart manager). Bot how to accomplish that, I do not know.
The short version, this is what I want:
- Detect if any of the Merge Modules (or older versions), which I am about to install, are in use (without using the Restart manager, sicne I need to support Win XP)
- If no, then just continiue, and do my registration at the end of the installation.
- if yes, then schedule the registration to happen after a reboot, and put said reboot in the end of the installation (do note, that my MSI is part of a chain, and is therefore launched from a parent-msi)
Any help to accomplishing this, is much appreciated
Thanks in advance
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Aug 09, 2012
04:32 AM
I managed to solve the problem myself 🙂
I removed the merge modules from my chained MSI, and put them as prerequisites (NMicrosoft Visual C++ 2010 Redistributable Package (x86)) for my main installation. In that way, they will all be in place before my own installation starts.
I removed the merge modules from my chained MSI, and put them as prerequisites (NMicrosoft Visual C++ 2010 Redistributable Package (x86)) for my main installation. In that way, they will all be in place before my own installation starts.
