Suite Behavior

[rguggisberg]

I am attempting to use a Suite project to create a single experience for uninstalling the currently installed packages of my Suite and reinstall the new packages (up to 4). (Lets disregard Upgrades for the moment… I will do that later. For now I need to uninstall some older versions). As suggested by Dlee65 on the 2013 forum, I have implemented Suite Actions to do the uninstall. The action is typically
C:\Program Files (x86)\InstallShield Installation Information\[ProductCodeMyProduct]\Setup.exe
With an argument of –uninst
I execute the Suite Actions on ‘Page Entered’ of a Wizard Page. This sort of works. I say sort of because if I put multiple Suite actions on a page it will only wait for the first one to complete before moving on to the next page. Seems like it should wait for each one in succession. So I made separate Wizard Pages for each package. It will uninstall the first 2 and then not proceed to the next page. If I cancel and restart it correctly proceeds to the third Wizard page and uninstalls the 3rd and 4th packages and hangs on the page for the 4th package. Can someone explain the flow of execution of a Suite? Is there a better way to do this? Even when I do get all the packages to uninstall it seems like I might have trouble switching from Maintenance mode to Install mode after Staging has been done???? Is there a way to basically direct the flow back to the beginning?

It seems like there may be a 'User Interface Sequence" and an "Execute Sequence" that are executing somewhat asynchronously??? Does anybody know?
Thanks!

[rguggisberg]

If I execute multiple Suite Actions on ‘Page Entered’ of a Wizard Page it launches the first one and then proceeds to Staging. How do I get it to wait for each Suite Action to complete before moving on?

Since that does not seem to work I made separate Wizard Pages for each Suite Action. It still advances to Staging immediately after launching the first Suite Action.

The Wizard Pages mentioned above are early in the list (before the Installation Welcome page).

Thanks for any ideas.

Update:
My Suite Action is a .exe and I have the Event Action 'Wait for Exit' set to "Yes".

I tested my .exe from a CMD prompt and the problem is that the .exe is Setup.exe (to uninstall) and that returns immediately 😞

[rguggisberg]

ok... so I did manage to get the process to wait for the uninstalls. There are a lot of places to run a 'Suite Action'... as an event, as a Page Entered or Page Exited event in a Wizard Page, as a Click event, etc.

What made it work the way I wanted (wait for uninstall) is to place the 'Launch executable file' action in 'OnStaging' with the proper condition. In the Wizard interface I have an Uninstall page that sets a couple properties (Caption and Summary) on the Install (Uninstall) Click. That page is followed buy a 'Please Wait' page that displays the packages being uninstalled along with the version. This page is displayed while all packages are uninstalled (which could not happen if actions were in OnBegin).

So far so good.. just what I want. Now how do I get it to reinstall the features that I just uninstalled? Is this not possible since everything was already Staged? Falling through to InstallationFeatures page does not do anything because, according to the log, "all operations have been completed".

Any ideas are appreciated.

[DLee65]

Uggg, this sounds very messy. What I do not understand is why you cannot simply just create upgrade packages for each MSI package in question. But I am assuming that there is some type of legacy issue that prevents a clean upgrade, such as I had with the Wise Installer installation package.

I am assuming that all the packages in question are MSI packages. If so then you will need to programmatically get the feature states for each package before uninstalling the packages. Then when you install your updated packages, pass in the parameter for the features to install. I forget what that is right off the top of my head but a quick google search for MSI PROPERTIES FEATURES should get you information.

So if this were me, in OnBegin, I would get the list of installed apps and retain that in a property somewhere.
During my wizard UI operating I would gather what information is required to complete the entire process, like selecting which packages to upgrade.
In the OnStaging event I would get the collection of features to install for each selected package, once complete I would uninstall each package to upgrade.
In the Installing code set your command line to include a formatted line with the necessary features for each package.

If the application package you are updating is SQL Server Express instance, then SQL Server includes the feature list in the registry under your instance name. I did this when we upgraded from SQL Server 2005 to 2012.
Hopefully this helps.

[rguggisberg]

Thanks Dan for the ideas.

I did file a support incident with Flexera and got some help but was ultimately told that regarding a Suite project…
“… the ability to create a single experience which involves the uninstall of a previous package (much like a major upgrade using Windows Installer) is not possible at this time. I will be adding your case to the work order. This is considered a product enhancement and at this time there is no time frame for when this will be resolved. The master issue number you can reference is: Master Issue Number: IOJ-1743145”

But for anyone who is interested… here is a summary of what I did to make it work for my purposes. Granted, there may be some shortcomings… one is that once the Staging event starts, you can’t cancel out of it nicely. And I did not consider a silent install, but that is N/A to me. So I respect Flexera’s position, as my implementation may not always be acceptable. It’s good to know that we may ultimately get this functionality in the product.

This works for me:

OnBegin
Used Suite Actions (1 for each package) to detect if packages were installed.
Condition - Registry Exists on HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield Uninstall Information\[ProductCode]

OnStaging (1 of each of these for each package)
1. Uninstall Package
Condition - All Packages Installed and None FeatureName Remove
2. Reinstall Package
Condition - All Package Installed and None FeatureName Remove

Wizard Pages
I added wizard pages to display the currently installed versions of my packages and allow user to click ‘Uninstall’ or 'Reinstall' to start and fall through to another page to wait for uninstalls.

[MichaelU]

I'm not sure I understand where the complexity is coming from. If we model this off a simple case, one might have v1 of a MSI package that needs to be upgraded to v2. It shouldn't inherently matter how v1 got onto the machine; the Suite with v2 can then install v2 which will either upgrade v1 or install v2 fresh. This shouldn't fall down unless the detection condition for the MSI was incorrect, and for an MSI package that shouldn't happen unless it's changed. And that should scale without difficulty to several MSI packages that apply either a minor or major upgrade. InstallScript packages should be similar, although they don't have the same names for their upgrades. I suppose InstallScript MSI or other EXE redistributables could provide challenges.

So what are the added complexities in your case, besides just having several packages?

• Do you have packages that cannot automatically upgrade just by installing v2 over v1, so must be removed?
  
• Do you have packages that you need to remove manually because they are not related to the ones in your new Suite?
  
• Do your detection conditions that indicate v2 is installed because they detect v1's presence?
  
• Do you need to specify default features by detecting v1 and turning on v2's feature?
  
• Are you trying to remove one or more previous Suites that have a different Suite GUID?
  

[rguggisberg]

My answers below...

MichaelU wrote:
I'm not sure I understand where the complexity is coming from. If we model this off a simple case, one might have v1 of a MSI package that needs to be upgraded to v2. It shouldn't inherently matter how v1 got onto the machine; the Suite with v2 can then install v2 which will either upgrade v1 or install v2 fresh. This shouldn't fall down unless the detection condition for the MSI was incorrect, and for an MSI package that shouldn't happen unless it's changed. And that should scale without difficulty to several MSI packages that apply either a minor or major upgrade. InstallScript packages should be similar, although they don't have the same names for their upgrades. I suppose InstallScript MSI or other EXE redistributables could provide challenges.

So what are the added complexities in your case, besides just having several packages?

• Do you have packages that cannot automatically upgrade just by installing v2 over v1, so must be removed? Yes
  
• Do you have packages that you need to remove manually because they are not related to the ones in your new Suite? No
  
• Do your detection conditions that indicate v2 is installed because they detect v1's presence?No
  
• Do you need to specify default features by detecting v1 and turning on v2's feature?No
  
• Are you trying to remove one or more previous Suites that have a different Suite GUID?No
  

[MichaelU]

Can you detect the v1 version separately from the v2 version? If so, I would probably lean towards having the v2 package in your suite detect only v2, and in its Package Configuring event, have it run an action that uninstalls v1, conditioned to run only if v1 is present. I haven't explicitly tried this, but it just feels to me like it puts the right pieces in the right places. It should apply equally well to first-time suite installs and suite-over-suite upgrades.

An optional variant of this is to create an exe package, marked as a dependency, with reversed detection conditions for the v1 package, and an Install operation command line that actually removes it. Order it to come before the v2 package, and it mimics the action approach, but requires at least one file be included in the package. This would have been the recommendation before actions were available.

I suspect even better would be to figure out how to have v2 replace v1, as it would probably be simpler to maintain than all the version-specific conditions for the above approaches. (But I'm saying that without knowing why your packages cannot replace their preceding version, so remember it's an unfounded opinion.)

[rguggisberg]

Michael,
Thanks for the reply. I will try some of those ideas when I get a chance. Right now things are working quite well for me as I have it. Have a few more things to do. The reason why my packages cannot replace their preceding version is because I am dealing with a lot of history. Some of these packages were done well before my time and did not uninstall properly. So for some versions we need to uninstall and run a cleanup utility before we can reinstall.