Is ANYBODY getting the desired Suite behavior?

[rguggisberg]

Is there anybody out there that is getting the hang of the Suite project and able to do what they want to do?
I was able to quite quickly get the LOOK that I wanted... but progress has ground to a near halt when it comes to getting the FUNCTIONALITY that I want. If you look at the posts on this site, there seems to be a lot of confusion regarding Detection Conditions, Eligibility Conditions, etc. I have read the posts and the Flexera documentation. I must say that I am quite disappointed with what I have found. For example, the doc on conditions mixes feature conditions and package conditions. Perhaps it is an excellent doc on Conditions. But there seems to be a dozen or so things that have to be correct to make it work. The problem is that if you mess up any one thing nothing works and it is very difficult to see what the problem is. I would like to see a 'View from 30,000 feet' so to speak and then an example of the steps to take to achieve results. Through some flailing and trial and error I have gotten things to install... but now I can't get Remove to work. I guess it is wishful thinking, but what I would like to see is a whole new document that first has an overall view and then goes through an example or 2 in the order that one needs to do things, rather than a general document on Conditions, another one on some other subject and then be left to try and figure out how it all works together.
But I digress. The problem I have now is with remove. I have several features, 1 package per feature, where each package is a single .exe file.
Remove: Yes
Target: setup.exe
Command Line /x
This does work if I execute from a command line. But if I execte Setup.exe it goes to Program Maintenance. When I click 'Remove' it goes to "installation Completed' and the status is: "The wizard was interrupted before My Project could be completely installed.
A log is attached. I suspect that the problem is with the "Parcel does not exist". I am sure that this is just something that I overlooked as I am trying to piece together info from random documents and posts.
Thanks for any direction.

[Shuttledude]

As far as your problem with uninstallation goes, try this:

In the "Remove" block, set:

Remove: Yes
Target: setup.exe
Command Line for basic msi package: /s /x /v/qb

Or, if you have an InstallScript msi package that uses an "answer" file (e.g., MY.ISS), the Command Line should be:

/s /f1"[SETUPSUPPORTDIR]\MY.ISS"

And you must add MY.ISS to the list of Support Files (under "Behavior and Logic") -- Language Independent is a good place. Right-click in the "Files" pane and choose "Insert Files", navigate to MY.ISS.

I have a suite install that silently installs and removes a few simple packages this way, just learning the basics at this point.

Hope this helps.

[MichaelU]

rguggisberg - If you are going to refer to setup.exe from your package, you probably need to cache it. The log shows an 0x80070002 error, which is File not found, when trying to launch setup.exe /x. If you do not want to cache the file, you might look for an alternate method of uninstalling, such as described on Package Operations - in particular consider how the reference "[ProgramFilesFolder]InstallShield Installation Information\{PRODUCT-GUID-HERE}\setup.exe" would work with an InstallScript installation.

As far as conditions being lumped together, it's because the way conditions are checked is identical anywhere in the engine side. The same behavior for the same kinds of checks power exit conditions, feature conditions, eligibility conditions and detection conditions. But then each of those conditions result in different run-time behavior:

• A true exit condition will cause the suite to issue a message and abort without doing anything.
  
• A true feature condition will cause a feature to be selected by default (which can be changed by the end-user if the feature tree is shown).
  
• A true eligibility condition indicates a package can be run on a target machine (for instance because all of its dependencies or operating system requirements are met). A false eligibility condition results in the package being ignored.
  
• A true detection condition indicates a package is present on the machine, so either can be removed, or at least doesn't have to be installed right now. A false detection condition generally indicates the package should be installed. This condition is also evaluated after running operations to assess whether the operation succeeded.
  

Does that help with the high level view?

[rguggisberg]

Thanks for the reply Michael.... that's good information, as usual.
I don't quite understand your statement about caching. It does not appear that there is a choice to NOT cache. My Cache Path is set to: [LocalAppDataFolder]Downloaded Installations
I have a Basic MSI installation.
I won't get to play with this much for a few days. When I get back to it, if there are no additional details posted here, I will try a different method of uninstalling.

**** Update ****
Ahhhh, just stumbled onto the setting in the Releases view, under Setup.exe. I will try that 🙂

[MichaelU]

By the time you have a suite and a basic MSI project (if installed through a setup.exe), there are two potential levels of caching. One is of the basic MSI's setup, which caches the .msi; the other is from the suite, which would cache the setup.exe or any other source files.

If you're going with a raw .msi, there's only one level of cache so this becomes a lot easier to describe. For clarity, the suite caches a package's data when the package has a Cache Path specified, and the release has Cache Packages Locally set to Yes.

Dependency packages on which you will never perform maintenance might be better off with their Cache Path not specified so their installation doesn't stick around on the machine. But primary packages generally need an entry point to perform an uninstallation, so they need to be cached unless there's another entry. Similar arguments apply to packages that support modification, or repair.