Suite UI level

[Johannes_John]

Hello,

how do I have an influence on the UI level of the called MSI?

CLIENTUILEVEL in den comandline is not successful, because of CLIENTUILEVEL is set to 3 at the end of the comandline.

Regards
Johannes

[MichaelU]

When you add a .msi installation to your Suite project as an MSI Package, we run it without UI. We expect people will want a single wizard, and will pull any questions into the Suite's interface.

If this is not the case, and you really want to show your original .msi wizard, you should consider adding it as an EXE Package. See Package Operations for more detail; there's some relevant pieces near the bottom.

[Johannes_John]

Hello Michael,

I don't rebuild all the dialogs of my setups into the suite.
And the logic of external setups?
And every setup with a new EXE shell?
Sorry.

And if I set the CLIENTUILEVEL in the commandline, it's overwritten by the value, which is set by suite.
And "/qf" results in error 1639.

My Quote, which can be read on many IS pages:
"InstallShield 2012's new Suite tool offers us a convenient way of integrating redistributable packages"
is going to burst like a balloon.

Regards
Johannes

[#4]

I think it's just a situation of having slightly different expectations for how things should work.

One of the principle concepts involved in the Suite UI is to provide a common interface that passes the necessary information off to its containing installations. This allows a consistent user experience while also abstracting out the intricate details of the suite that's unimportant or irrelevant to the person carrying out the installation while focusing on those elements that are more important for someone executing the installation.

It looks like you're more interested in having some combination of the contained installations' UIs running at some point during the install?

[Johannes_John]

Hello bryanwolf,

Thanks for your reply!

When the default is without UI - o.k.
But there should be a easy posibilty to set these parameters e.g. in the commandline.

Regards!
Johannes

[#6]

No debate that might be helpful, but what might be best is if we fully understood why you'd want to set this. This way, when we get to looking at solving your problem, we can provide the best possible solution for you instead of one that only meets your immediate needs (and possibly falls short).

Are you looking to have specific UI show up at a certain time or can you explain what specifically you're going to have show up?

[Roman1]

Hello,
I have also written an setup wrapper,
which works similary to Suite.

Some global inputs are making in wrapper wizard.
Other I am giving in commandline to subsetups.

Two setups becouse of their complexity are running in NOT-SILENT
mode.

So, I would welcome the possibility of giving original commandline to subsetups.

Thanks.

[Johannes_John]

Hello bryanwolf,

I don't expect to rebuild all the dialogs of .NET, of VisualStudio, or third party setups ( if they have one ).
I don't want to rebuild the dialogs of my setups ( several target directories, source directories for data of old versions, dialog for IIS and so on )
And if each setup has its own target directory?
For which directory you want to ask for, if the features in the suite aren't selected at this time?
And by the way, in the directory search, there's no possibilty to select UNC pathes.
And it's only possible to select existing directories. The way to let the user create the dirs in the search dialog... In my opinion not the best way.

And the logic of the setups, e.g. about the access to an exist file? What's about the error message? All messages in all variations and all variables in there? "File ... is locked by user ???!" Where to get the username?

And what's about the license agreement.
Whose license agreement? The agreement of MS .NET? This of MS VisualStudio? This of my company? This of a third party company?
Which one will be shown in the suite? All of them?

My opinion: Let each setup ask, what he thinks to need.

Regards
Johannes

[Roman1]

Hello,
I would mention, there was not a Beta Test Phase for IS2012.

Perhaps we are beta tester, now?

[#10]

Thanks for the feedback. Just so you know, we do have beta programs. Our gold support level provides you with priority invites to beta programs for products of which you are a customer. More information on the feature sets provided by support plans can be found here: http://www.flexerasoftware.com/support/maintenance.htm

If you'd like to review your service level to ensure you get priority invites, please contact the Account Administrator listed in your support plan.

For the multiple EULA problem, a possible solution (may not work admittedly):
There's a predefined dialog that would allow you to show another installations EULA. You can see this by right-clicking on the Wizard Panes node and selecting the "Add Predefined Page" option. There's a page called "View and Accept Supplemental License Agreement" that you can add. As long as you can access the EULA of the sub-installation then you should have no issues with something like that. For the most part, redists like .NET and Visual Studio don't have complex dialog sequences (VS only has a large number of feature sets), so it's probably more a legal matter in whether they can be hidden without issue or not.

Otherwise:
I'm not sure how to best address all the issues you've listed, but they're good things for us to think and talk about. Thanks for being forward with the issues you're encountering. Providing an override to the installed package's UI could be a good solution. The main concern at that point is figuring out the best time to show it and all that sort of thing. But, now that we have some solid context to go on, I think we can find ways to support these scenarios.

[MichaelU]

To echo a bit of what Bryan said, and to mention a few more things, our goals with Suites have had two main areas of focus:

• Install multiple packages
  
• Enable the creation of a a simple unified UI, allow complex ones
  

The first is really a matter of taking our prerequisites and chaining support (from previous versions of InstallShield) to the next level, and giving you the hooks to let you select packages like you select features or components today.

The second seems to be where we're disagreeing about the approach the most. Lots of end users don't want to or aren't knowledgeable enough to deal with tons of questions. They can't even answer whether they want the .NET framework, much less what directory they want some other prerequisite installed to. To support this end of the spectrum, we allow for asking as little as you can imagine, and specifying defaults in the Suite project, and passing these defaults to your packages via their Install operation's command line.

However your target audience might be a little more knowledgeable than the end users I mentioned above. Perhaps they are at home with installations that ask questions as complex as Microsoft SQL Server Express does today. For this end of the spectrum we allow you to add all the controls you need to ask these questions, and with SP1 will allow you to write code to implement the custom logic to power listboxes or comboboxes, and validate the resulting choices or other entries as you see fit.

Somewhere between those two ends are cases where you need medium complexity; perhaps you need supplemental EULAs, or maybe to allow choosing a couple target directories. To that end, Johannes John's point about UNC paths is well taken. You can work around this today by changing the label to an edit box and allowing the user to type directly, but without valdiation that might be a little scary; we can look into turning on UNC path support from our end as well.

For Roman1's question about command lines, we do not support arbitrary command lines on the Suite's setup.exe, but we do support arbitrary properties. You could then pass this entire property into one of your packages. For example, if you have an MSI package with MYPROP="[MYPROP]" on its install operation's command line (or an EXE package with [MYPROP]), and call setup.exe MYPROP="some value" it will be passed through.

[Roman1]

Hello,
we have gold maitenance support.
We were not informed about IS2012 Beta tests.

Are you working on IS2012 SP1 ???

MichaelU:
Thanks for the solution proposal about command line!
But, it is not usefull...



What about such scenario:
There are 3 msi-setups in suite.
What does happen if one of them in error runs?
Does the whole installation stop?
Are the other (errorless) installed setups autom. deinstalled?

Thanks

[Johannes_John]

Hello bryanwolf, hello Michael,

Again:

no UI as default - o.k.

But let there be a easy posibilty without making changes at the called MSI to set this parameter.

Please let us decide, where the user answers which question.

Regards
Johannes

[Roman1]

Hello,
using chained installations we are also able to set command line.

Please, take this calling system as example.

[MichaelU]

@Roman1: If a package fails, normally the entire suite will fail. If the packages are part of a transaction running on a system with MSI 4.5, they will be rolled back. You can tweak this with settings on the package, however if none of your packages manage to install successfully, this may appear to confuse the suite engine.

@Johannes John: Noted; we will consider this as an enhancement request to allow selecting to display the UI from a MSI package during a suite installation. In the meantime, you'll have to stick with the much less convenient pattern of putting the MSI in an EXE package.

[Johannes_John]

Well.
Is there a time window, when a SP concerning this case will be published?
Regards

[MichaelU]

We're not really committing yet. But previously I've stated this, and it still holds.