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
- :
- [Suite]Problems controlling feature package install
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
‎Nov 13, 2013
03:29 PM
[Suite]Problems controlling feature package install
I have a couple of questions regarding implementing features and associated packages.
1. What controls the order in which features are installed.
2. If I have a feature that I am controlling during the install through the UI, using FEATURE[featureName].actionState=install, does this change the order in which it is installed? If so can I then alter its position?
Basically I have a custom page in my wizard UI that contains two radio buttons.
On radioButton1 Events I set the click set Property Condition Name FEATURE[featureName].actionState value to install
On radioButton2 Events I set the click set Property Condition Name FEATURE[featureName].actionState value to an empty value
The debug log reveals that the values are updated correctly.
However, my feature package is not installing at the correct time. The feature package is listed as a dependency, but it still launches after the primary.
It is acting as if it is listed last in my list of features. I was thinking that the order in which the items are listed in my development UI controls the order in which packages are installed. But that does not appear to be true. That is why I am theorizing that it is due to my changing the actionState value.
Is there anything else I can do? I don't think I should have to manipulate the actionState of the primary package just to reorder the state of the dependency package.
EDIT: From the help documentation:
"At run time, the Setup.exe file launches each package based on the conditions that you have defined and the order in which you listed the packages in the Packages view."
Currently this is not true for my installation. The package under 'featureName' is listed second in my Packages view. But it is installing last. When I remove the events from the radio buttons then the package will install in the correct sequence. By deduction, altering the actionState also alters the package sequence. This really breaks what I really intend as a developer. I want to keep the same sequence, just toggle on and off the actionState. I cannot change the sequence as SQL Server must be installed BEFORE my main application. But NOT all target machines will require SQL Server.
1. What controls the order in which features are installed.
2. If I have a feature that I am controlling during the install through the UI, using FEATURE[featureName].actionState=install, does this change the order in which it is installed? If so can I then alter its position?
Basically I have a custom page in my wizard UI that contains two radio buttons.
On radioButton1 Events I set the click set Property Condition Name FEATURE[featureName].actionState value to install
On radioButton2 Events I set the click set Property Condition Name FEATURE[featureName].actionState value to an empty value
The debug log reveals that the values are updated correctly.
However, my feature package is not installing at the correct time. The feature package is listed as a dependency, but it still launches after the primary.
It is acting as if it is listed last in my list of features. I was thinking that the order in which the items are listed in my development UI controls the order in which packages are installed. But that does not appear to be true. That is why I am theorizing that it is due to my changing the actionState value.
Is there anything else I can do? I don't think I should have to manipulate the actionState of the primary package just to reorder the state of the dependency package.
EDIT: From the help documentation:
"At run time, the Setup.exe file launches each package based on the conditions that you have defined and the order in which you listed the packages in the Packages view."
Currently this is not true for my installation. The package under 'featureName' is listed second in my Packages view. But it is installing last. When I remove the events from the radio buttons then the package will install in the correct sequence. By deduction, altering the actionState also alters the package sequence. This really breaks what I really intend as a developer. I want to keep the same sequence, just toggle on and off the actionState. I cannot change the sequence as SQL Server must be installed BEFORE my main application. But NOT all target machines will require SQL Server.
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 15, 2013
04:03 PM
Your needs here describe exactly what we designed for, so I'm hoping this is a misdiagnosis. After the user clicks the Install button, the suite examines the packages in order. For each package it checks a combination things related to the conditions and the associated features' action states, and then chooses whether to install, uninstall, repair, modify, or ignore the package. I have no reason at all to expect that changing the feature state could change the order in which a package is processed; it should only be able to affect what the processing actually does. Can you reproduce this reordering in a sample project you can share here?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 18, 2013
10:29 AM
Michael, I totally agree with you.
I reverted my project to an earlier version of the project and tried setting the event action state of radio buttons again. This time with my tests on a very clean Windows 7x86 machine it was recognizing that I changed the state of the radio button but the event action never triggers.
So I began to get very suspicious of my entire work environment and shut down the Virtual Machine that my development environment lives in, and my host environment.
I restarted this morning and rebuilt the project and so far the project is behaving just as I had wanted it to in the first place. I have not changed any code from last week just recompiled the project.
I cannot believe that in all of this process I had not tried tech - 101 reboot the d@mn machine. 😄
Now I cannot explain why this is making a difference but if it works I will not complain.
But I will leave this here as a friendly reminder to others, if your build is acting differently than you expect, try rebooting not only your guest environment (if operating in a virtual environment); but also the host environment.
I reverted my project to an earlier version of the project and tried setting the event action state of radio buttons again. This time with my tests on a very clean Windows 7x86 machine it was recognizing that I changed the state of the radio button but the event action never triggers.
So I began to get very suspicious of my entire work environment and shut down the Virtual Machine that my development environment lives in, and my host environment.
I restarted this morning and rebuilt the project and so far the project is behaving just as I had wanted it to in the first place. I have not changed any code from last week just recompiled the project.
I cannot believe that in all of this process I had not tried tech - 101 reboot the d@mn machine. 😄
Now I cannot explain why this is making a difference but if it works I will not complain.
But I will leave this here as a friendly reminder to others, if your build is acting differently than you expect, try rebooting not only your guest environment (if operating in a virtual environment); but also the host environment.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 18, 2013
03:02 PM
In the 'Packages' view you can specify the behavior you want for a 'Reboot Request' for Install, Remove, Repair, Modify. Do you have the Install behavior set to "Ignore the reboot request"? If so, you may want to make a more appropriate choice. 🙂