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
- :
- Shared packages require both suites to be IS 2015?
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
‎Jul 22, 2015
03:06 PM
Shared packages require both suites to be IS 2015?
I have a suite built with IS 2015 that has a shared dependency package. I have another suite built with IS 2014 that has the same dependency package (same Package GUID). According to the help file "If two Advanced UI or Suite/Advanced UI installations share different versions of the same package, the later version of the package is the one that is installed on target systems after both Advanced UI or Suite/Advanced UI installations are run, regardless of which one was run first". In my case, the IS 2014 suite has a newer version of the package and is installed first. The IS 2015 suite then fails to install because it tries to install the shared package and detects that a newer one is already installed. I suspect, and would like to confirm, that I need both suites built with IS 2015 for shared packages to work properly.
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 23, 2015
07:57 AM
Correct; the bit from the help that you mention only applies when a package is marked shared in all suites that have installed it, or may be about to install it, on a given machine. Since IS 2014 didn't have the option to mark a package as shared, that's not the scenario you are in.
For that matter, the shared package option in general only works cleanly when all things that deliver it use the same sharing mechanism. In practice, this means that it should always use an IS 2015 or later suite, and always (or never) mark it shared. What happens when you cross this line? If you are matching or upgrading a non-shared or pre-IS2015 package into a shared IS2015 package, it should mostly work; however, the sharing side may never remove the package as it cannot tell when the non-shared reference such as a IS2014 suite is removed. In contrast, the non-sharing side (the IS 2014 suite) will do whatever it did before, including possibly removing the package before the sharing side (IS 2015 suite) has been removed. We'll need to see how this plays out more in practice, but our current hunch is that such packages should typically remain as prerequisite-style dependency packages (i.e. they have no Remove operation). The downside to this approach is that it doesn't offer a good path towards enabling sharing.
If I'm reading correctly, the case you describe has a second twist. Not only are you upgrading InstallShield and trying to turn on package sharing, but the newly shared package would skip installing because it's a downgrade from its non-shared predecessor. Instead of skipping installation and tracking shared counts, it fails the install; is that correct? Just to be sure, it has the same package GUID, right? We'll have to think this through a bit more; it's possible that there's something we need to do to make this scenario better. (Although it will never be quite as a clean as a pure sharing scenario.)
For that matter, the shared package option in general only works cleanly when all things that deliver it use the same sharing mechanism. In practice, this means that it should always use an IS 2015 or later suite, and always (or never) mark it shared. What happens when you cross this line? If you are matching or upgrading a non-shared or pre-IS2015 package into a shared IS2015 package, it should mostly work; however, the sharing side may never remove the package as it cannot tell when the non-shared reference such as a IS2014 suite is removed. In contrast, the non-sharing side (the IS 2014 suite) will do whatever it did before, including possibly removing the package before the sharing side (IS 2015 suite) has been removed. We'll need to see how this plays out more in practice, but our current hunch is that such packages should typically remain as prerequisite-style dependency packages (i.e. they have no Remove operation). The downside to this approach is that it doesn't offer a good path towards enabling sharing.
If I'm reading correctly, the case you describe has a second twist. Not only are you upgrading InstallShield and trying to turn on package sharing, but the newly shared package would skip installing because it's a downgrade from its non-shared predecessor. Instead of skipping installation and tracking shared counts, it fails the install; is that correct? Just to be sure, it has the same package GUID, right? We'll have to think this through a bit more; it's possible that there's something we need to do to make this scenario better. (Although it will never be quite as a clean as a pure sharing scenario.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 23, 2015
10:37 AM
Michael, thanks once again for an informative and detailed reply. You've confirmed that I need to upgrade the IS 2014 Suite to IS 2015. As we are still in development this shouldn't be any problem.
Our situation is that two of our products will be sharing a configuration editor. Since one product is in beta and the other in development we are just starting to encounter sharing problems. What we want is the following:
1. Only the latest version of the shared package will be installed. If an earlier version is present it will be skipped.
2. When all shared references are removed the package will be uninstalled.
To confirm, the package GUID is the same in the IS 2015 and the IS 2014 suite. The IS 2015 suite fails to install when a newer version of the shared package has been installed by the IS 2014 suite. At present we are working around the problem by manually uninstalling the newer version.
Let me know if you require any more details.
Our situation is that two of our products will be sharing a configuration editor. Since one product is in beta and the other in development we are just starting to encounter sharing problems. What we want is the following:
1. Only the latest version of the shared package will be installed. If an earlier version is present it will be skipped.
2. When all shared references are removed the package will be uninstalled.
To confirm, the package GUID is the same in the IS 2015 and the IS 2014 suite. The IS 2015 suite fails to install when a newer version of the shared package has been installed by the IS 2014 suite. At present we are working around the problem by manually uninstalling the newer version.
Let me know if you require any more details.
