Suite Project Documentation...

[Superfreak3]

Hi all,

Just switched to IS 2012 Premier and I'm looking to leverage the Suite Project for one of our products.

I was just wondering if there was a consolidated document somewhere containing the ins and outs of this Project type. The user manual doesn't really contain much and I did see some scattered docs in the KB.

Any help appreciated!

Thanks!

[MichaelU]

I would suggest reading a combination of the online help and our blog posts on Suites (see the list of the latter at http://community.flexerasoftware.com/showthread.php?t=199170).

[DebbieL]

No, we don't have any consolidated documentation of just Suite info at this time. If you haven't already, you'll also want to review the InstallTalk blog, where we've posted a number of technical articles on Suites. Refer to my blog sticky near the top of this forum for links and more details.

[Superfreak3]

Thanks for the info.

A big issue for me will be running some type of actions during the suite install since there is a lot of configuration that needs to be done post install to get all of the pieces of the suite to work in concert. Hopefully actions are doable.

[MichaelU]

Actions in the suite will run with the UI permissions, so they may not have privileges to change things. Depending on exactly what the configuration is, it would probably make sense in one of the existing installations, collection into a new helper installation package, and/or done by the applications themselves at first launch. Care to share more detail on what sort of configuration so I can be more specific?

[Superfreak3]

Two of the installations that will be included in the Suite are third party items. Following their installation, there are some cmd line actions that need to run. Also, I have to edit some config files, etc.

Once I dig deeper into our existing mechanism I can provide more specifics if needed.

[MichaelU]

Ahh, well if you have command lines, you might be able to wire those up as EXE packages without a need for actually packaging them up. While the IDE will require you to select an EXE when adding an EXE package, you can then rewire it to reference a run-time exe location (such as [SystemFolder]cmd.exe) and remove the EXE. Of course if these are console EXEs, it will probably flash a command prompt window unless you use a different approach.

[Superfreak3]

My initial thinking was that I would wrap all of the configuration and command line calls up into an .exe. If this is possible, could this then be added as a package to fire off as part of the suite? I guess I would just fire this with no conditions.

What I'm planning on doing is go through my current installation script (calls two third party .exe's then our product's .msi) and summarizing what it does. Maybe I'll add that summary here in the next day or two to see what is possible.

First, however I'll run through the docs pointed two from this thread.

I'm a little confused as to what the Package Type setting (Primary/Dependency) is used for. I would like for the suite to act as follows...

Check conditions of first package and install if not there.
Check conditions of second package and install if not there.
Check conditions of third package and install if not there.

[Superfreak3]

Our current installation mechanism handles 'suite' requirements by displaying a page indicating what is lacking (from registry checks primarily). Buttons are enabled to allow launching of suching things as a .NET Framework installer, Java runtime installer, etc from the source media.

I guess I would have to handle these with action .exe's called as packages as well with appropriate conditions. ??

Our current requirements page will refresh periodically indicating to the customer when all requirements are properly installed. They would then navigate to another screen that displays the suite pieces to install.

I don't know that I can maintain this with InstallShield's Suite Project. ?? I did see that .dll functions can be called from a Suite installation. Maybe I can handle Prerequisites that way. ??

[MichaelU]

Right, the Suite approach to this would be to replace buttons, that directly launch the installer, with checkboxes or features which choose whether the package (with said installer) will be installed. This way the user can make all the selections up front, click Install, and go home for the day (or just go get coffee).

Now it is possible to still do it the way you describe. You can create an action which launches an installer, prompt for its own elevation via UAC (if, as default, the Suite wasn't marked for elevation), and then tweak properties to update the indicators. But it's going to be significantly more work.

[Superfreak3]

I plan on reading the Suite blog posts today, but...

I plan on requiring Admin rights for the Suite in general. Will this then launch packages with those credentials?

Also, all three of the packages that will be contained in the suite are needed for our app to work properly so I really want to remove the need for the user to select anything or have them intervene to launch the installs (can live with if needed though).

Like I said, I hope to summarize our current code soon to see how feasible a switch to a Suite Project might be.

Basically it goes something like this...

Detect and Install Package 1
Make any needed configuration tweaks via some type of action
Detect and Install Package 2
Make any needed configuration tweaks via some type of action
Detect and Install Package 3 (our package)
Make any needed configuration tweaks via some type of action

A hurdle that I can think of off the top is the Detection of Package 2 (Glassfish). They really leave no real traces of installation in the registry. I guess I could search for some file, but I don't know how long a system wide search would take since I have no real way of grabbing the install path. Currently I grab and parse from a Program Group shortcut.

Anyway, I could ramble (if I haven't already 🙂 ), but I'll try to get a bit more detail.

I would really like to move to this approach as it would be easier to localize as well.

Thanks again for all of the information so far!!

[MichaelU]

Oh, perfect. It sounds like you want to move towards the most common path for Suites. Perhaps make feature selection available, perhaps just install, and let the package detection conditions control what happens from there. This should be pretty smooth for you.

[Superfreak3]

Smooth, I like to hear that. Yes, I would prefere the Suite process to handle everything with as liittle intervention on the part of the end user as possible.

I just worry about the configuration tweaks, command line calls, etc that have to be handled by some sort of action(s). I'm eager to look at the DLL function call blog article. Hopefully that will be the solution.

Thanks again, and more to come!!

[Superfreak3]

OK, I've gotten around to the reading and I have a few initial questions. I don't know if its best to just ask questions as I go or dump them in one lump post, but here goes...

I will have 3 Main packages in early thinking... Viewer, Glassfish, OurProduct. Not sure which of these should be primary or if all should be. They are all needed, but the only one that will be removed will be OurProduct. I think I want to leave the others behind and only act upon them when we get an update from the third parties.

Would it be best to add these to one feature that is always marked for install?

I'm thinking the package operations will be Install only for the Viewer and Glassfish packages and Install, Remove, Repair for OurProduct.

My next thought is to handle prerequisites such as .NET and Java runtime/jdk as separate packages that would be dependencies. I would check a registry entry for installation state and set a property or the Feature to install. Does this sound about right?

Another area that I'll need to address is answer files as support files for the Viewer and Glassfish installations if the user elects to install them silently. I see I can add new Wizard pages to gather needed info, but I would then have to have an action to edit the answer files with this input. Is this where a .dll might come in?

Again, I wish to make the installation of our product along with third part pieces as seamless as possible with as little user intervention as possible. I should say, if you haven't gathered already, that I am quite excited with regard to the prospects of the Suite Project!

Again, sorry for the bugging and thanks for the help so far. It is more than appreciated!

[Superfreak3]

Quick Question as I'm still reading through the documentation...

On the Welcome page, I want to display a hyperlink to download the Adobe Reader if not installed on the system. How do I undertake a registry search to populate a property?

I would then use {Binding MyProperty == MyValue}, but I don't know how to populate MyProperty.

Is this possible with the Suite Project?

Or should I be making the Adobe installer a package and use detection conditions. The only problem with this is that some users want to read our docs up front at the onset of any installations. If Adobe would be present, i would use conditionally displayed links or buttons to point to various .pdfs in the SupportDir.

Or would this be a job for a dll call to dig in the registry then set a Suite property? If so, its documented that a c/c++ dll can be used so I take it that a VB.Net custom action is out of the question. ??

[MichaelU]

There's a behind-the-scenes approach to the system search style functionality you want, where you can put a condition inside a element. Since you're looking for present/absent, this is a pretty easy case to do with that. Otherwise a full on action would be a good idea (although one wrapped up in a condition can run earlier). But you're right; managed actions aren't yet supported in the Suite UI. I don't know if we'll add them at some point.

Typically I would make Reader a dependency package for this scenario; this avoids extra UAC prompts and the like. Is it common for a machine not to have a PDF reader already installed?

Dependency vs Primary package really only influences when you run maintenance or first-time installation. While we think of Dependency packages as a mapping of prerequisites, and thus typically suggest they not be uninstalled, it's not a completely clear decision on that. What's more important is what you want your suite to do if only package C is present: is this maintenance (make it primary), or is this a first time install (make it a dependency). Then I think you have the operations spot on for what you describe.

Suites will work best when you can pass the options to your packages on their command lines. This typically already works for MSI packages, and you might consider making a helper EXE for the others which turns command-line parameters into configuration file changes. If you go with actions instead, you'll have trouble running the relevant actions in a silent suite installation. Maybe we should add a hook for that...

[Superfreak3]

Typically I would make Reader a dependency package for this scenario; this avoids extra UAC prompts and the like. Is it common for a machine not to have a PDF reader already installed?

I don't know that it is typical in this day and age that machine would not have a pdf reader installed. We've had that detect, launch installer functionality in for several years now and just never bothered to re-evaluate the need or change.

Currently we detect, display a link if lacking to launch an Adobe installer .exe to allow for the reading of our docs. I think I may have mentioned earlier that if I do replicate this behavior in install rework (possible switch to Suite) I would just redirect the user to a download site instead.

I don't know if I could make this a dependency package because I get the complaint that users want to read the documents up front before any transactions take place on the target machine (How many actually read them is another issue.). Suite installations work in a fashion that once packages start being installed, they all go in sequence, correct? I couldn't display a welcome screen, install Adobe if lacking, display a couple more screens, install the rest of the packages I wouldn't think.

[Superfreak3]

MichaelU wrote:
There's a behind-the-scenes approach to the system search style functionality you want, where you can put a condition inside a element. Since you're looking for present/absent, this is a pretty easy case to do with that. Otherwise a full on action would be a good idea (although one wrapped up in a condition can run earlier). But you're right; managed actions aren't yet supported in the Suite UI. I don't know if we'll add them at some point.

Is that in the issuite file? If I dig around in there, will I see an example of how to utilize the method? I'll also look through the blog entries again for an example.

[Superfreak3]

MichaelU wrote:
Dependency vs Primary package really only influences when you run maintenance or first-time installation. While we think of Dependency packages as a mapping of prerequisites, and thus typically suggest they not be uninstalled, it's not a completely clear decision on that. What's more important is what you want your suite to do if only package C is present: is this maintenance (make it primary), or is this a first time install (make it a dependency). Then I think you have the operations spot on for what you describe.

The first two packages that will be installed are needed for/by our app, third package. I was thinking of making those dependency and our app the primary. However, what would happen then if package one and/or two needs to be updated. If the Suite launches in maintenance mode for our product, will the first two packages be evaluated/installed as needed.

Another thing that makes our current setup tricky is that if one of the first two packages are updated, a repair install of our app's .msi is fired. This is because there are some custom actions that need to run to edit some configuration files places by the dependency packages. Is this something that would be possibly with the Suite?

[MichaelU]

You can definitely replicate the link to the Reader installer in Suites. However making it install automatically in time to use it to launch a pdf from a button in your wizard will probably require an extra UAC prompt.

I don't think we've blogged about the properties yet, but it matches the format of other conditions. If you want to condition the , add something like inside it (you'll have to split the SetProperty into a and a ). You can have multiple SetProperty elements that each set the same property; the last one with a true condition "wins".

I'm not quite sure how the Suite will handle the partial upgrade case you describe. If they should act like dependencies that are always installed, it should be easy enough to ensure they install. But if they're on their own feature, it may be hard to differentiate between the feature having been unselected at an earlier point and the package needing an upgrade. Similarly it should be possible to force a repair, but doing it at just the right times might be tough. I suspect some suite actions that run on, say, the Install button might be the best way to implement some of these cases.

[Superfreak3]

MichaelU wrote:
I don't think we've blogged about the properties yet, but it matches the format of other conditions. If you want to condition the , add something like inside it (you'll have to split the SetProperty into a and a ). You can have multiple SetProperty elements that each set the same property; the last one with a true condition "wins".

I guess I'll have to wait until the SetProperty blog comes across the wire. Not quite sure of the convention. What is this based on? Is this an InstallShield thing or some wider XML standard. As you may have realized by now, I'm no XML expert (but more than willing to learn).

I'm just wondering why stuff like this is not documented somewhere or is it because I'm exploring a behind the scenes method.

As far as the Adobe requireing an additional UAC prompt. I'm not too worried about that. Like we discussed earlier, this may be a rare need in this day and age. Also, this is a web application that is installed on one machine in a particular users environment so its not that much of a hassle.