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
- :
- Changes to how product configuration and release flags are handled in 2010
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 25, 2009
07:26 PM
Changes to how product configuration and release flags are handled in 2010
After being a bit confused after upgrading my projects from InstallShield 2009 to InstallShield 2010 resulted in some of my prerequisites being included when they previously were being excluded, I stumbled on the documentation in the release notes.
Now I remember back in InstallShield 2009 when I was having so much fun trying to get the product configuration and release flages to work as desired. Anyway, it is not the end of the world and I'll just rework how I define the product configuration and release flags in relation to prerequisites and features. Thought I'd bring it up for others in case they had similar issue as the behavior changed.
IOC-000074931 (Basic MSI, InstallScript MSI)
When you have specified release flags and product configuration flags for a release that you are building in the Releases view, InstallShield now properly includes and excludes InstallShield prerequisites that have release flags. That is, if you assign a release flag to an InstallShield prerequisite and also specify that flag for the release, for the product configuration, or for both, InstallShield includes that InstallShield prerequisite in the release at build time. Previously, the InstallShield prerequisite was excluded from a release if either set of flags in the Releases view did not match the flag that was assigned to the prerequisite.
Now I remember back in InstallShield 2009 when I was having so much fun trying to get the product configuration and release flages to work as desired. Anyway, it is not the end of the world and I'll just rework how I define the product configuration and release flags in relation to prerequisites and features. Thought I'd bring it up for others in case they had similar issue as the behavior changed.
(11) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 27, 2009
02:22 PM
For the record, I think the change is good.
Also, by revisting how I was doing my release flags it ended up a more simple solution.
Also, by revisting how I was doing my release flags it ended up a more simple solution.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 27, 2009
02:36 PM
Thanks. It definitely made things more consistent with other parts of the product that used release flags, so I'm glad the end result is also better for you.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 28, 2009
10:29 AM
Hopefully you can help, I'm very confused with this change. We recently purchased IS2010 to upgrade from IS11.5. When I converted and built my project, no files were included and it's taken me two weeks (working with Acresso support) to finally figure this out on my own that the release flags was the issue. (here's the incident number I've filed with support: #SIOA-000153991)
Subfeatures with flags that aren't in the higher level feature (above the subfeature) are not including in the release with that specific subfeature flag. This is a very large difference for our project if this is correct.
After converting the project to IS2010 from IS11.5, if I create a new top level feature with a new flag and use that with one of the existing components/files then assocated that new flag with a release, the file is added. But if I move that newly created feature under a previously created feature, then it doesn't include the file in the build.
So can I still have multiple layers of features/flags and how does it work in IS2010 as apposed to IS11.5? I want my subfeature to have a specific flag that is not in it's parent feature.
I tried attaching a zip file for you of a sample project I can show you the issue, but it's 5MB. It's attached to the support incident #SIOA-000153991.
This project is way overdue b/c of this issue so please help. Thanks for any additional help here.
Subfeatures with flags that aren't in the higher level feature (above the subfeature) are not including in the release with that specific subfeature flag. This is a very large difference for our project if this is correct.
After converting the project to IS2010 from IS11.5, if I create a new top level feature with a new flag and use that with one of the existing components/files then assocated that new flag with a release, the file is added. But if I move that newly created feature under a previously created feature, then it doesn't include the file in the build.
So can I still have multiple layers of features/flags and how does it work in IS2010 as apposed to IS11.5? I want my subfeature to have a specific flag that is not in it's parent feature.
I tried attaching a zip file for you of a sample project I can show you the issue, but it's 5MB. It's attached to the support incident #SIOA-000153991.
This project is way overdue b/c of this issue so please help. Thanks for any additional help here.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 28, 2009
01:32 PM
I'm not certain from your message whether this is the case, but it sounds like a different change in release flags handling might be at work here. At some point in the past, when you had a parent and child feature with different release flags such that the parent would be excluded and the child would not, the child bizarrely became a top-level feature. Since the change in IS2008, once the parent feature is excluded, all its child features are also excluded, so as to avoid changing the topology of your feature tree.
If you somehow need the old behavior, you should be able to get close to it by creating a duplicate top level feature that shares all the components of the child feature, and flagging it the opposite way. For reference, the original defect addressed by this change was logged as IOC-000056123 (you can find this in the IS2008 release notes).
If you somehow need the old behavior, you should be able to get close to it by creating a duplicate top level feature that shares all the components of the child feature, and flagging it the opposite way. For reference, the original defect addressed by this change was logged as IOC-000056123 (you can find this in the IS2008 release notes).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 31, 2009
10:33 AM
Thank you for your response Michael. That does sound like what is happening.
I now am confused with how the features/flags work with the new IS versions. So if I have a parent feature, three child features and each child feature has 2 children like my illustration below. How would I include only feature CHILD_b without including CHILD_a or any other features in FEATURE_1?
-FEATURE_1
-CHILD_1
CHILD_a
CHILD_b
+CHILD_2
+CHILD_3
+FEATURE_2
+FEATURE_3
Thanks for your help.
I now am confused with how the features/flags work with the new IS versions. So if I have a parent feature, three child features and each child feature has 2 children like my illustration below. How would I include only feature CHILD_b without including CHILD_a or any other features in FEATURE_1?
-FEATURE_1
-CHILD_1
CHILD_a
CHILD_b
+CHILD_2
+CHILD_3
+FEATURE_2
+FEATURE_3
Thanks for your help.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 31, 2009
03:07 PM
I'm not sure what the best approach would be, but what I described above would mean you'd create a clone of that feature at the root level, called CHILD_b_clone, which includes the same components as CHILD_b. This has some downsides, like advertised shortcuts might not work just right under these features. Then set the release flags to trigger at opposite times, so either FEATURE_1 and CHILD_b are included or CHILD_b_clone is included
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 01, 2009
10:05 AM
Your suggestion sounds like it might work but I have several hundred child features and would rather just do it correctly instead of putting them all at the root level.
I can't seem to find any examples of how to use release flags with multiple levels of child features. I'm just confused on how this should work at this point. Is there any documentation you can point me to? Seems odd that I'm the only one experiencing this with this update...are flags/features not highly used by others?
Thanks for getting back to me and for your continued help.
I can't seem to find any examples of how to use release flags with multiple levels of child features. I'm just confused on how this should work at this point. Is there any documentation you can point me to? Seems odd that I'm the only one experiencing this with this update...are flags/features not highly used by others?
Thanks for getting back to me and for your continued help.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 01, 2009
10:40 AM
I think we might need to redirect this question towards what you're trying to accomplish by excluding root level features when you want to include their children features. Is there a better way to structure this that actually does what you want with the adjusted rules?
The way it works is pretty straightforward. When a feature is excluded by release flags, all of its component links are discarded, as are all of its children features. When the last link to a component is discarded, the component and its files, registry, etc., are excluded.
The way it works is pretty straightforward. When a feature is excluded by release flags, all of its component links are discarded, as are all of its children features. When the last link to a component is discarded, the component and its files, registry, etc., are excluded.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 01, 2009
02:34 PM
Fair enough. Just for the record, I do think this is a more solid way of doing this. I was just taken surprise by the change. Similar to what you explained, this is what Acresso support suggested...(just info for any others).
"
Given the following structure that you described:
FEATURE1
--CHILD1
-----CHILD_A
-----CHILD_B
To include feature CHILD_B, you would need to include CHILD1 and FEATURE1 features since these are parent features of CHILD_B. CHILD_A can however be excluded because it is on the same level as CHILD_B. This will also mean that you will need to associate release flags to FEATURE1 and CHILD1 to include them in the build. Excluding CHILD1 means that all features under it are also excluded.
"
Thank you so much for your help Michael! I'd have never figured this out without your help. I'm going to restructure my features/flags layout for my project.
"
Given the following structure that you described:
FEATURE1
--CHILD1
-----CHILD_A
-----CHILD_B
To include feature CHILD_B, you would need to include CHILD1 and FEATURE1 features since these are parent features of CHILD_B. CHILD_A can however be excluded because it is on the same level as CHILD_B. This will also mean that you will need to associate release flags to FEATURE1 and CHILD1 to include them in the build. Excluding CHILD1 means that all features under it are also excluded.
"
Thank you so much for your help Michael! I'd have never figured this out without your help. I'm going to restructure my features/flags layout for my project.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 14, 2009
09:22 AM
To add a release flag to an InstallShield prerequisite that you have added to your installation project:
In the View List under Application Data, click Redistributables.
Right-click the InstallShield prerequisite and click Properties. The InstallShield Prerequisites Properties dialog box opens.
In the Release Flags box, type a string. The string can be any combination of letters or numbers. To have more than one flag on a prerequisite, use a comma to separate the flags.
but in installshield 11.5 properties option is disabled.
In the View List under Application Data, click Redistributables.
Right-click the InstallShield prerequisite and click Properties. The InstallShield Prerequisites Properties dialog box opens.
In the Release Flags box, type a string. The string can be any combination of letters or numbers. To have more than one flag on a prerequisite, use a comma to separate the flags.
but in installshield 11.5 properties option is disabled.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 16, 2009
07:51 AM
The ability to assign release flags to prerequisites was added in InstallShield 12. InstallShield 11.5 did not have this capability.
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)