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
- :
- Re: Suite project: Packages in subfeatures are not filtered based on release flags
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
‎Mar 05, 2014
09:23 AM
Suite project: Packages in subfeatures are not filtered based on release flags
I have a suite project organized in the following way:
Feature_A
I have created two releases (CD-ROM and Web) that use the CD and Web release flags, respectively. If I run a full install of the CD-ROM release on a 32-bit system, the following packages are installed: A1,A3. None of the Packages included in Subfeature_AA are installed. Checking the installation log, I find the following entry:
Parcel {GUID for Package_AA2} mapped to feature FaroArmUsb was not found
There shouldn't be any reference to Package_AA2 at all. It should have been filtered out of the release based upon the release flags. In contrast, Package_A2 is not referenced in the log at all.
This error seems to break the action states for all the parcels in the subfeature. All of the final action states of the parcels are set to 5, resulting in none of them being installed.
As an experiment, I moved Subfeature_AA left, so that it is a top-level feature. When I do this, everything works as expected. I am left with the conclusion that the build engine does not filter out packages based on release flags when those packages are in subfeatures.
Can anyone confirm this? I hope I've explained it adequately. It's not the easiest thing to communicate.
Feature_A
Subfeature_AA
Package_AA1 (Release flag: CD)
Package_AA2 (Release flag: Web)
Package_AA3 (32-bit msi, No Release flag)
Package_AA4 (64-bit msi, No Release flag)
Package_AA2 (Release flag: Web)
Package_AA3 (32-bit msi, No Release flag)
Package_AA4 (64-bit msi, No Release flag)
Package_A1 (Release flag: CD)
Package_A2 (Release flag: Web)
Package_A3 (32-bit msi, No Release flag)
Package_A4 (64-bit msi, No Release flag)
Package_A2 (Release flag: Web)
Package_A3 (32-bit msi, No Release flag)
Package_A4 (64-bit msi, No Release flag)
I have created two releases (CD-ROM and Web) that use the CD and Web release flags, respectively. If I run a full install of the CD-ROM release on a 32-bit system, the following packages are installed: A1,A3. None of the Packages included in Subfeature_AA are installed. Checking the installation log, I find the following entry:
Parcel {GUID for Package_AA2} mapped to feature FaroArmUsb was not found
There shouldn't be any reference to Package_AA2 at all. It should have been filtered out of the release based upon the release flags. In contrast, Package_A2 is not referenced in the log at all.
This error seems to break the action states for all the parcels in the subfeature. All of the final action states of the parcels are set to 5, resulting in none of them being installed.
As an experiment, I moved Subfeature_AA left, so that it is a top-level feature. When I do this, everything works as expected. I am left with the conclusion that the build engine does not filter out packages based on release flags when those packages are in subfeatures.
Can anyone confirm this? I hope I've explained it adequately. It's not the easiest thing to communicate.
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 05, 2014
09:45 AM
I had a similar problem; however, I was not using sub-features. However, none of my release flags on the packages were honored, just on features.
I was able to get around the problem by creating new top level features that have the correct release flag.
When I tried to replicate the problem with a brand new suite package with a sample install, then I could not. So whatever it is, it is something in the structure of my xml. I don't have the time to completely debug the issue and do not want to recreate my suite package from the ground up since I have a significant amount of work into it now. If it were just a matter of adding packages and testing that would be one thing but now I have custom references to InstallScript events and other actions.
If I remember correctly Michael had tried to reproduce the error but was not able to. Perhaps your instructions will enable him to do so.
I was able to get around the problem by creating new top level features that have the correct release flag.
When I tried to replicate the problem with a brand new suite package with a sample install, then I could not. So whatever it is, it is something in the structure of my xml. I don't have the time to completely debug the issue and do not want to recreate my suite package from the ground up since I have a significant amount of work into it now. If it were just a matter of adding packages and testing that would be one thing but now I have custom references to InstallScript events and other actions.
If I remember correctly Michael had tried to reproduce the error but was not able to. Perhaps your instructions will enable him to do so.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 05, 2014
10:21 AM
Is it possible that you used IS 2013 Beta on the project and upgraded the project to IS 2013? I had an issue with that, but not sure if it was same.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 05, 2014
10:26 AM
This is a project that I created from scratch in InstallShield 2013 SP1 to rule out any possible upgrade issues. I'm actually building the suite project on my build machine, however, which uses the IS 2013 SP1 Standalone Build. I'll try building it in the IDE and will post if I get different results.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 05, 2014
10:37 AM
It is possible that this was even an upgrade from IS2012 because I started this project back when we had this version but then got pulled away from the project to work on maintenance issues for the Wise Installer projects. When I came back to the project the 2013 release was available and I am certain I installed SP1 immediately.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 06, 2014
01:19 PM
A simpler case with two features (NewFeature, and SubFeature as its child) and one release-flagged package on each feature, seems to work correctly (removing both when I flag them off).
If any of you can share an .issuite file that has this problem (I shouldn't need any supporting files), I can look into what's going wrong. Our release flags filtering shouldn't care about feature depth, so the described symptoms aren't making much sense to me. (If you can share, but the .issuite file needs to stay confidential, I can accept it by email / PM.)
If any of you can share an .issuite file that has this problem (I shouldn't need any supporting files), I can look into what's going wrong. Our release flags filtering shouldn't care about feature depth, so the described symptoms aren't making much sense to me. (If you can share, but the .issuite file needs to stay confidential, I can accept it by email / PM.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 07, 2014
10:02 AM
Ah, thanks! I missed a subtlety here in the problem; your diagnosis of sub-features was spot-on. I've identified what's happening and we'll be able to fix it. As a workaround, you should be able create hidden sub-features (set Visible to False) that have release flags like the packages (or instead of the packages), and I believe that will resolve the dangling reference. Let me know if you need any clarification on this workaround.
For reference, we're tracking this as IOA-000124405.
For reference, we're tracking this as IOA-000124405.
