Additional install as a custom action weirdness

[Seth]

Here's another good one for you guys. I have another application (aka
TheirApp) that I would like to install with my application (aka MyApp). I
have no control over TheirApp, so I have just have to use what's given to
me. TheirApp is an older InstallShield setup that is spanned over 11 disks.
So I included all 11 disks in my install. Then I added a custom action at
the end of MyApp's execute sequence that launches the setup.

This seems to work fine, but here's where the weirdness comes in. Every
once in awhile, in the middle of TheirApp's install (which is launched by
MyApp), InstallShield freaks out and asks for a file in disk 5 or whatever.
So I point it to the directory and it claims that it can't find it even
though I know it's there.

If I try to install MyApp without the custom action, everything works fine.
And I can manually run TheirApp's setup that is installed but not launched
by MyApp with no problems.

Anyone seen anything like this? I've been banging my head against the wall
for several days on this bad boy. Any info would be definitely appreciated.

Thanks,
Seth

[Rich [Microsoft Windows Installer MVP]]

[Please do not mail me a copy of your followup]

"Seth" <a...@b.com> spake the secret code
<us#S3Ab1BHA.1288@tkmsftngp07> thusly:

>This seems to work fine, but here's where the weirdness comes in.

I guess "seem" is the operative word here. Personally, I stay away
from launching other installs from inside my install. Instead I use
a launcher program that sequences the dependent installs.

I just don't think launching other installs from inside Windows
Installer is a good idea. We get lots of posts here about these
sorts of problems and they generally go away if you don't launch the
legacy install from inside a Windows Installer install. I use an
HTML application as my autorun program which serves as my launcher,
but you could just as easily use a program with no UI that does the
necessary stuff.

There are other horror stories in the archives about this same
situation.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
Direct3D Book http://www.xmission.com/~legalize/book/
izfree: Open source tools for Windows Installer
http://izfree.sourceforge.net

[Seth]

Could you provide some more info about your method? How would I create a
launcher program for it? Is your HTML application some sort of custom
action? I feel like your post totally lost me.

Thanks again,
Seth

"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>
wrote in message news:a7t22r$l42$1...@news.xmission.com...

[Rich [Microsoft Windows Installer MVP]]

[Please do not mail me a copy of your followup]

"Seth" <a...@b.com> spake the secret code

<#9NgFCc1BHA.2052@tkmsftngp05> thusly:

>Could you provide some more info about your method? How would I create a
>launcher program for it? Is your HTML application some sort of custom
>action? I feel like your post totally lost me.

First, check <http://groups.google.com> and search this group for
"launcher" or "dependent install" and that should turn up the old
threads on this subject, which may be of help.

In my case the "launcher" is the program launched by the AutoRun
mechanism when you put a CD-ROM in the drive. In my case, the
sequence goes something like this:

- CD-ROM is inserted
- AutoRun starts
- the launcher is started by AutoRun
- launcher probes the system to determine necessary requirements
like the presence of Windows Installer and DirectX
- launcher provides GUI for instructing the user through the
dependent installs

I have a small C++ program that obtains the version of Windows
Installer present on the system and also the version of DirectX present
on the system. It then passes these two versions to an HTML
application (which is just HTML + VBScript) that provides the user with
an interactive way to select the installation of the Windows Installer
runtime and/or the DirectX runtime before installing the stuff
associated with my book (which is on Direct3D, depends on the DirectX
8.1 runtime and the installation itself depends on Windows Installer).

So the "launcher" is a program that handles the dependent installs --
in my case Windows Installer and the DirectX runtime. Both of these
cannot be launched robustly from inside my install. For the former,
if Windows Installer isn't present on the system, obviously I cannot
use Windows Installer to install the stuff from the CD-ROM. For the
latter, you -must- execute the included setup.exe for DirectX, you
can't launch their MSI from inside your MSI. Both WI and DX may
require reboots of the system as they are system components and
rebooting in the middle of your install (or even before your install
has finished) is likely to generate headaches.

My choice of an HTML application requires IE5, so you may want to use
a C/C++ program instead if you don't want to require this. (In my
case, if launching the HTA doesn't work, I fall back to displaying a
README.TXT which gives instructions for how to do things manually.)

For your case, you have a program that should be installed along side
your application. It sounds like you don't require that program to
be installed before yours, just along with it. You'll need to ask
yourself what happens when the second application is already
installed or won't install from your distribution. Those are
conditions you'll have to deal with robustly.

It sounds to me like your launching sequence could be like this:

- launch your MSI to install your product
- launch the associated application's SETUP.EXE to install
the companion product

Things get slightly more complicated if either your product or the
companion product require reboots. Then you'll probably want to have
your launcher start again after the reboot. This can be tricky if
the SETUP.EXE also wants to continue after the reboot.

[R. Michael Sanford]

Seth, don't believe the crap some people will throw at you about needing a
separate launcher. The problem you are experiencing has a cause and a
solution and with some patience and understanding you will solve it. The
overhead of writing a robust launcher is just not worth it when all you are
really doing is spawning an .exe in much the same way WI does.

My suggestion: Clean out your temp directory and use FileMonitor from
sysinternals.com to watch what is happening as the msi and the other install
runs. Odds are that there is a collision as compressed files are extracted
into a temp directory...

HTH

"Seth" <a...@b.com> wrote in message news:us#S3Ab1BHA.1288@tkmsftngp07...

[Seth]

Thanks for the tip. I tried using filemon, but with no luck. It didn't
report any problems as far as I could tell. Everything is a success and
then it just dies. This problem is just too odd, damn MSI is gonna give me
an ulcer.

"R. Michael Sanford" <msanford...@hotmail.com> wrote in message
news:erImg7c1BHA.1796@tkmsftngp02...

[Seth]

Thanks for the more information. I still don't understand why the custom
action won't work. It seems to me that I have such a simple install. MyApp
installs, and then then last thing it does is fire off the install for
TheirApp. Neither of the installs require a reboot. And neither of the
installs are directly dependent on each other. It's just nice to have
TheirApp when MyApp runs. It seems so silly that the install for TheirApp
works fine on its own, but if you let the MSI fire it off, it pukes. I
totally understand your need for a launcher, since you must have DirectX and
WI installed before you go any further, but I don't have anywhere near those
kind of strict requirements.

Ugh, the thought of writing an additional app for this seems like so much
overhead. But it seems like it might be the only way. Once again, thanks
for all your help and info.

Seth

"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>

wrote in message news:a7t6dv$mhh$1...@news.xmission.com...

[R. Michael Sanford]

Can you post more details? What is the product? What exactly is in your
CustomAction Table? Post the contents of that row. Post your sequence
table too as that may help solve this...

Lastly, have you contacted the vendor? They may be aware of the problem and
have a solution for you. And, as a last resort, consider searching the
InstallShield site for similar issues. You may find a solution there.

"Seth" <a...@b.com> wrote in message news:uJl70wn1BHA.2136@tkmsftngp04...

[Seth]

Here is the row in the CustomAction table (don't mind the wacky source,
that's VSI for you):

Action: InstallOPCServer
Type: 82
Source: _2053B34DAA6F4DEEBFE8D7FBCAF19A41
Target: setup.exe

I also added a row to the InstallExecuteSequence:

Action: InstallOPCServer
Condition:
Sequence: 6700

6700 makes it the very last thing to happen, it follows InstallFinalize.

Unfortunately, I have no contact information for the vender (it's a long
story). I attempted looking around InstallShield's site for something, but
couldn't find anything useful.

Thanks again,
Seth

"R. Michael Sanford" <msanford...@hotmail.com> wrote in message

news:exL4Dpo1BHA.1160@tkmsftngp04...

[Rich [Microsoft Windows Installer MVP]]

[Please do not mail me a copy of your followup]

"Seth" <a...@b.com> spake the secret code

<#w9vO1n1BHA.2388@tkmsftngp05> thusly:

>[...] It seems so silly that the install for TheirApp

>works fine on its own, but if you let the MSI fire it off, it pukes.

It doesn't seem silly at all to me. An installation should be
considerd an atomic action and complete fully before you attempt
another install. You're invoking another install from inside your
install before your install is completely done.

[R. Michael Sanford]

Thanks for the info.

A type 82 is a standard exe installed with the product, with the "Ignore
Return Value" bit set. All things considered, that should be fine...

Things to try:
Change it to deferred and toggle the "No Impersonation" flag (1106 and 3154
I think...)
Run it asynchronously (146)
Write a quick little utility to call CreateProcess and CreateProcessAsUser
(That is all WI does internally...)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/pro
thred_6pf6.asp

I've seen situations where the "Setup.exe" is really just a self-extracting
stub executable. When called, it will extract some files, start the install
by running another .exe, then continue extracting, and terminate when it's
done. If it terminates too soon and cleans up the extracted files, the
install can fail saying it can't find disk n or something along that line.
Use WinZip or something similar to see if the exe contains a compressed
resource.

"Seth" <a...@b.com> wrote in message news:eXKfA6o1BHA.1552@tkmsftngp05...

[Rich [Microsoft Windows Installer MVP]]

[Please do not mail me a copy of your followup]

"Seth" <a...@b.com> spake the secret code

<#w9vO1n1BHA.2388@tkmsftngp05> thusly:

>Thanks for the more information. I still don't understand why the custom

>action won't work. [...]

Well maybe now you see why I just don't recommend doing this...