2 replies to this topic

[deramor]

All-

 

I ran across what installshield support calls expected behavior but I view as a bug.  I wanted to report it here in case anyone runs into it.

 

Use case:

User installs a suite project release.  This suite project is uncompressed and user opts to not install all of the "features" or packages.  Later, through Programs and Features, user installs any number of the remaining features.

 

In this scenario, the source for each added package can not be found.  User is presented with a dialog asking for the source of each package being added.  Apparently in compressed and Web type releases, the suite project will locate the source for all packages during a Modify or Repair operation.  This is not true if the suite is un-compressed.

 

I had the support person enter a bug and engineering will evaluate the behavior.  If anything changes, it will make its way into a future release.

 

I do not have a workaround except to use a web or compressed release.

For me, I can't compress my suite package since the resulting setup.exe file will be greater than 2 GB in some cases.  I don't want to load that large of a file.  The installation would take much longer than it should.

[Stefan Krueger]

So are you saying that even if "Cache Packages Locally" is set to "yes" the package is not cached, or it doesn't find/use the cached copy?

[deramor]

I'm not really sure what that setting is used for.  If yes, the packages do get copied locally.  However I can't tell if they are executed from that cached folder or from the original media.  Further, when the Suite is fully removed, the cached packages remain on the system.

 

During modify/repair operations, the source media is still requested even if the package was cached.  So I have no idea what good it does to cache anything at this point.  They don't seem to be used for modify, remove, or install.  And to make matters worse, they are left on the system after the suite is removed.