PDA

View Full Version : Need Help With Exit Condition in Suite



rguggisberg
05-31-2012, 08:51 AM
I can't get ANY behavior out of an Exit Condition in a Suite. I have read the help, and the links it references, which lead to further references, which lead me back to where I was... but I am obviously missing some key piece of information.

I have two releases with different GUIDs and I want to exit with error immediately if the other release is already installed.

What I have done is left the 2 original Exit Conditions that are placed by default and added a 3rd one:
Any
Suite Installed
Suite GUID: {GUID of my other Release}
Version: 0
Comparison: GreaterThan

All of which does not seem to matter, as I have tried numerous combinations. I see this info in the .issuite file if I open it with NotePad, but I see nothing in the log file when I search for things like "SuiteInstalled" or "SuiteId". Where in the sequence of things does this exit condition get evaluated at runtime? Is it possible that I am missing the whole mechanism due to ordering of wizard pages?
At run time, it immediately goes to the Maintenance Welcome screen.
Thanks for any assistance.

BTW, It works exactly as I would expect if I have a newer version of the Suite installed (aborts immediately with message)... but I still can't get it to abort if a specified Suite GUID is installed or if a specified registry key exists.

rguggisberg
05-31-2012, 12:02 PM
I can get the exit condition to happen if I have the other Suite installed with NO packages (sort of an illegal condition that I arrived at through this attempt to not allow both releases to be installed). So evidently the Exit Condition is being checked much later than I expected. Maybe it is checked on exit.... If so, the help is misleading; because it says that you can check for proper OS, etc... which you would do at the beginning and not at the end. Does anyone have an explanation?
Thanks.

rguggisberg
06-04-2012, 09:07 AM
After further testing I am convinced that the Exit Conditions do not work as they should. As a simple test I did this:
Installed Version 4 of Release B and then did an IS build for version 3 of Release B.
1. Using default Exit Conditions - Verify that it aborts with message if you attempt to install an older version. That works as expected.
2. Change Suite Guid from * to actual GUID number and change Version from * to 0. Still works as expected.
So far so good! Now...
Uninstall Suite and install version 3 of Release A.
3. Change Suite Guid in Release B to GUID number of Suite A and rebuild Release B. On install it does not abort with error... it goes straight to Mainenance mode.
Any ideas? Thanks!

MichaelU
06-04-2012, 03:03 PM
Exit conditions are not evaluated if the installation is present (as determined by the detection condition of a primary package); this avoids the need to write the "OR Installed" style modification familiar to MSI's launch conditions.

rguggisberg
06-05-2012, 07:16 AM
Michael,
Thanks for the reply. I see what you are saying... but Exit Conditions are evaluated if the installation is present. For example, the suite aborts immediately if a higher version is already installed.

Wish I would have caught this in beta and asked you to add Elegibility Conditions to suite as we have for packages :( I'll have to figure something else out now.

rguggisberg
06-05-2012, 01:46 PM
:( I thought I might be able to put an eligibility condition on each primary package to make it ineligible if a specified suite was already installed, but I can't seem to make that work either.

Short of writing a dll, is there no way to execute some action to read the registry or check for an installed suite to set a property, which I could use to redirect the flow in the suite?

rguggisberg
06-05-2012, 04:15 PM
Michael,
Well I have struggled and can't seem to find a way to do what I want to do, which is to not allow the installation of a suite if another suite with a specified GUID is already installed. Your statement that

"Exit conditions are not evaluated if the installation is present (as determined by the detection condition of a primary package); this avoids the need to write the "OR Installed" style modification familiar to MSI's launch conditions."

seems to be in direct conflict with the help topic "Suite Installed Condition Settings", which states...

"The Suite Installed setting shows the condition that is configured for checking whether a particular version of an Advanced UI or Suite/Advanced UI installation is already installed on a target system."

That even goes as far as allowing you to enter a particular GUID... so it would appear that it was intended to be more flexible than just checking the version of the current suite.

MichaelU
06-06-2012, 09:21 AM
It's been just long enough since I was deep into this, so I'd better verify my original claim, but they are not in conflict. There are two things that are subtly different here, and it's good to understand how they differ.

First is the one I referred to, which has been around since the beginning of suites: the mode condition. This is a condition we build out of the detection condition of your primary packages which allows us to determine whether the suite should run in a first-time install or in a maintenance mode. If your detection conditions are precise, this is a very precise condition.

Second is the one we added in the IS 2012 Spring release, the Suite Installed condition. This condition checks the version information stored by a registered Suite and was added primarily to ensure that suites upgraded well. It does this by being incorporated into the default Mode condition, turning a case with a matched GUID but differing version into a first-time install so that the exit condition for the downgrade scenario has a chance to fire.

If you're looking at this like "whoa, what a hack", I won't completely disagree, but it does hint at the basis for how to do what you want. If you open up the .issuite file directly, you can now find the <Mode> element with /Mode/Install/When/Any[/Not/DetectPrimary]/SuiteInstalled pre-populated. I think for your case you will want to add another <SuiteInstalled .../> with your other GUID, forcing a first-time install, as well as an exit condition to match.

rguggisberg
06-08-2012, 01:06 PM
Michael,
Thanks a lot. With your suggestion I can make it do exactly what I want :)

For anyone else that might attempt to do this. Here's what I did.
My package detection conditions were already set up. I opened the .suite file with Notepad and added 2 lines as shown below: (I have included default surrounding code.)

ADDITION #1 - This one does not show up in IDE.
<Mode>
<Install>
<When>
<Any>
<Not>
<DetectPrimary Id="*"/>
</Not>
<SuiteInstalled SuiteId="*" Version="*" Compare="NotEqual"/>
*** I added this line *** --> <SuiteInstalled SuiteId="{GUID-Of-My-Other-Package}" Version="0" Compare="NotEqual"/>
</Any>
</When>
</Install>
<Maintenance>
<When>
<Any>
<DetectPrimary Id="*"/>
</Any>
</When>
</Maintenance>
</Mode>

ADDITION #2 - This one shows up in IDE.
<AbortConditions>
<Message Text="IDS_SUITE_MINOR_DOWNGRADE">
<When>
<Not>
<ParcelRef Id="*"/>
</Not>
</When>
</Message>
<Message Text="IDS_SUITE_MINOR_DOWNGRADE">
<When>
<Any>
<SuiteInstalled SuiteId="*" Version="*" Compare="GreaterThan"/>
*** I added this line *** --> <SuiteInstalled SuiteId="{GUID-Of-My-Other-Package }" Version="0" Compare="NotEqual"/>
</Any>
</When>
</Message>
</AbortConditions>

MichaelU
06-08-2012, 02:05 PM
Cool, glad you got what you want. One thing I didn't call out so clearly, but want to mention for the case you've described here, is that you'll want to be careful what the behavior is when you install this-package, install other-package, and try to uninstall this-package (or run any sort of maintenance). If bombing out is okay, or if you similarly prevent the installing other-package when this-package is installed, you're probably fine. But if you want to allow for removing this-package, you'll need to craft more elaborate conditions.

rguggisberg
06-08-2012, 02:22 PM
Michael,
Thanks for looking out for me! I think I am set the way it is. Basically my 2 suites are mutually exclusive. So if any part of one suite is installed I want to bomb out ASAP if the user attempts to run Setup.exe for the other suite.

Thanks again. I would not have gotten it done without your help.

IlkkaV
03-25-2013, 05:23 AM
Bumping an older thread, but I'm having a somewhat similar problem that I can't seem to get solved. My scenario is that my suite project consolidates two MSI packages (32-bit and 64-bit versions of the same product) that were previously installed using separate installers. As the MSI's required some modifications when including them in the suite project, their product, upgrade, and package codes were changed. Now, just to avoid all kinds of conflicts I've tried to make it so that if the previous MSI packages are detected, the suite installation aborts with a message telling the user that the previous package should be uninstalled first (yes I know, not the most elegant solution, but better than completely messing both versions). However, every time I launch my suite installer when the previous MSI package is installed, the suite installer goes straight into maintenance mode even though the new MSI's should be completely different packages from Windows Installer's viewpoint. How could I detect what exactly triggers the maintenance? /debuglog tells me the following:


3-25-2013[12:05:47 PM]: Determining setup mode...
3-25-2013[12:05:47 PM]: Engine: no command line mode specified, evaluating setup.xml install mode block for mode
3-25-2013[12:05:47 PM]: Engine: final mode we're running in: 1
3-25-2013[12:05:47 PM]: Engine: mode is maintenance: yes

I've tried modifying the eligibility and detection conditions for both suite and the primary packages, but the result is always the same. What's the correct place and way to detect the presence of the MSI packages so that the exit conditions actually work? The SuiteInstalled trick mentioned in this thread didn't seem to work, and I guess this is due to the fact that the packages aren't suite packages. Should I use some other property in a similar manner?

IlkkaV
03-26-2013, 08:45 AM
Hmm, seems like I got it working now. Noticed that I had an overlapping detection condition, which apparently overruled the eligibility and exit conditions.