Prerequisites: Make 'Open Site' run after other apps install

[cbono]

Hello A.I. folks,

I have 3 Software Prerequisites. The first 2 are of type 'URL' (download from Web and install), while the 3rd is of type 'Open Site'. The 3rd prerequisite has the 2nd as its Parent; I don't want #3 to run until #2 is found to have been installed.

My problem comes from how the Prerequisites Wizard steps through the process. On a clean machine (where all 3 prerequisites will run), it downloads the first 2 prerequisites. This works great; I like the UI and it seems simple to understand:



Now, I think the best next step would be to go ahead and INSTALL these prerequisites. But instead, what happens when I click "Next>" is:



Even though I've marked this last Prerequisite as dependent on the second one (which isn't installed yet), the Wizard pops open this page. It feels wrong; I haven't finished with my first task (which was installing those downloads), and now the Wizard is prompting me to download software from another website. I'm afraid some of our customers will get mixed up here and not know what to do. It's even worse that the Wizard screen is now obscured by the IE window.

Is there any way I can force this 'Open Site' prerequisite to fire ONLY after I've installed the first 2 downloads? If not, I feel strongly enough about this that I'd either remove this as a prerequisite, or get the direct download and install like I do the first 2. Since it's Adobe Reader, I'd kind of like to leave it going to the Download page. Reader is a "suggested" application to fulfill our requirement of "PDF viewer application". I don't necessarily want to force install this software if our users would rather get something else.

Best,
Chris

[Cosmin]

Hi,

When the prerequisites feature was designed, we established that the "Open Site" option is a bit special because it basically launches an URL and lets the user handle the rest. After the user continues, the detection criteria of the prerequisite is checked to see if it was installed correctly.

Since the prerequisite wizard must wait for the user to continue, it needs to show a custom dialog not related to the other types of prerequisites. We decided that this dialog should be shown first and this type of prerequisites should be executed before the other prerequisites, therefore you encountered the expected behavior.

However, based on your example I have added on our TODO list an improvement which will allow "Open Site" prerequisites to be treated like the other types of prerequisites. Thank you for your suggestion.

Reader is a "suggested" application to fulfill our requirement of "PDF viewer application". I don't necessarily want to force install this software if our users would rather get something else.

Please note that the user can choose which prerequisites will be installed through the wizard. If he doesn't want to install one, he can simply uncheck it. Also, when configuring the Adobe Reader prerequisite you can set the display name to something like this: "Adobe Reader (optional)". This way the user will know that it is not mandatory and he can uncheck it if he wants.

Regards,
Cosmin

[cbono]

Cosmin,

As always, thanks for your response. It's helpful to hear the thought processes behind features of your product. Overall, I do think it will be better to treat 'Open Site' prerequisites like others, and allow us developers to choose the point in the install process where it's displayed.

After doing some thinking about our "PDF/Adobe Reader" requirement, I think what I'll actually do is point to a page on our website. In this way, we can provide supplemental instructions to our users, as well as point them to a few alternatives to the Adobe Reader product.


Best,
Chris

[cbono]

A quick update.

Since the PDF viewer is not a "hard" requirement (our customers can use the application with no errors; it's just not as rich an experience), we decided to drop it as a formal Prerequisite.

Instead, we now use a Predefined Custom Action of type "Launch File or Open URL" to do basically the same thing. We set up a special registry key search on the "Search" page to detect whether or not PDF is a handled type. Then based on the result of the search's associated Property, we condition the custom action. If necessary, it runs in the InstallFinalize stage. The task flow is improved a lot over how we were trying to do it.

And we are directing the users to a custom web page to help them understand the requirement and choose between a couple different supported PDF applications.

A.I. is a great product with a lot of flexibility. Sometimes you just have to do some lateral thinking to come up with the best solution.


-Chris