Possible to change the temp directoryused during install?

[Heather B.]

Hi there,

A problem we're having is that my program's installer is unpacking, and
then, strangely, it is kicking off the installer files from another install
program for a completely different program that was installed on all of my
users' desktops a year ago. This other program's installer, it turns out,
did not clean up after itself, and left its install files in the Windows
Temp directory that is used by my program's installer (again, built using
ISX3.51), and the install files are getting tangled.

Is there a way in ISX 3.51 to change the temp directory that is used to
unpack and install our application? That's the best fix I can think of.

Has anyone else encountered this? (Somebody has to have experienced this.)
Is there a better fix that I am unaware of?

Many thanks!!!

Heather

[reply@installshield.com Chandima Rajakaruna]

Are you including the MDAC merge module in your setup? If so this is a known
issue. If you are not distributing MDAC merge module I would like more
details on your setup. Like

1. Single Exe or CD Rom media?
2. Compressed or Uncompressed?
3. Using Support Files?
4. How many Custom Actions (if any)?
5. Are you using any Custom Actions to perform a nested install?

Thanks.

"Heather B." <heat...@NOSPAM.attglobal.net> wrote in message
news:3bb370e7$1...@news.installshield.com...

[Heather B.]

1. Single .exe and Web deployable setup.cab built with isx3.51 both exhibit
same behavior.
2. Compressed. Will uncompressing help?
3. Like what, for example?
4. 3 custom actions. One to restart after the install, one that kicks off
my own vb app which installs Palm hotsync components for our app after the
ISX install, and one that kicks off the MDAC_typ.exe after the welcome
dialog.
5. See 4, just above.

Thanks,
Heather

"Chandima Rajakaruna" <no re...@installshield.com> wrote in message
news:3bb47ce5$1...@news.installshield.com...

[James P. Hoffman]

You have a custom action, in VB, that runs just after installing the
application on a machine that didn't previously have VB? I didn't know that
would work; have you had any problems?

Pete Hoffman

"Heather B." <heat...@NOSPAM.attglobal.net> wrote in message

news:3bb7bf07$1...@news.installshield.com...

[reply@installshield.com Chandima Rajakaruna]

By default a Single Compressed exe extracts stuff to the Temp Folder and
runs it from there. Maybe it's mixing up setups at that point. I'll take a
look at that scenario. Couple of suggestions

1. Try with an uncompressed build
2. In the web deplyoment wizard make sure "Copy media to target location" is
checked. Also try setting a different directory for this setting.

"Heather B." <heat...@NOSPAM.attglobal.net> wrote in message

news:3bb7bf07$1...@news.installshield.com...

[reply@installshield.com Chandima Rajakaruna]

It shouldn't have nay problems, because if you do a Static Scan on a VB
project, it will automatically add the VB merge module (which contains the
VB runtimes). So these files are copied to the target machine during the
install.

"James P. Hoffman" <jpho...@velocenet.net> wrote in message
news:3bb85200$1...@news.installshield.com...

[reply@installshield.com Chandima Rajakaruna]

Actually a Compressed Setup simplay extracts the msi and cab files (not
Setup.exe itself) to a sub folder in the temp directory. So this means it's
not mixing our packages Setup.exe with something else. So I guess the
culprit is MDAC_TYP.exe. Try the setup after disabling the Custom Action to
make sure. The reason this happens is because Mdac_typ.exe extracts all it's
files to the Temp Folder and then run's IT'S Setup.exe. So if there already
is one in the temp folder it probably mixes it up with that one.

"Chandima Rajakaruna" <no re...@installshield.com> wrote in message

news:3bb89549$1...@news.installshield.com...

[Heather B.]

I just realized that we just started using mdactyp.exe. We were using your
merge module until we decided we were having too many problems with that. I
tested the install without mdac and the custom action, and it is not the
culprit. Still has the problem, unfortunately.

Any other ideas what could be causing the tangling?

Heather

"Chandima Rajakaruna" <no re...@installshield.com> wrote in message

news:3bb898f2$1...@news.installshield.com...

[Heather B.]

Never had a problem with this. I was wondering the same thing, but after
about 150 installs on Win98 (both original and second edition) and Win2000,
I've never seen this fail.

What drove me to try this was that we had a strange bug in our install where
our custom action refused to kick off an executable that I downloaded from
Palm.com, which installed Palm Hotsync components on the client machine. I
have no idea why, but the custom action was just ignored, like it wasn't
there. Out of curiosity I threw together a vb app that just has a sub
main() and which shells out a launch command to execute the
PalmCOMInstaller.exe. Works like a charm, has never failed. Turns out VB
offers a fabulous way to very quickly make highly customize custom actions
that are conditional upon specific registry settings, or anything else you
can dream up.

ISX allows you to add registry settings conditionally based on the features
selected by the user, however, custom actions can't be tied to features.
As a work around to this missing functionality, I've inserted registry
entries indicating the features chosen by the user, and I've added a custom
action to launch a tiny VB executable later in the install. That little VB
exe checks the registry entry to determine the features chosen by the user,
and then proceeds based on the registry entries it finds. Using this
method, I've effectively tied custom actions to the user selected features
(in this case, whether the user want the components that support Palm
hotsyncing installed along with my application).

Hope this helps...

Heather

P.S. If you are following this thread, then you might ask if the palm
components are the culprit in my original note and the answer is no, I've
tested that - no such luck.

"James P. Hoffman" <jpho...@velocenet.net> wrote in message
news:3bb85200$1...@news.installshield.com...

[reply@installshield.com Chandima Rajakaruna]

What happens if you disable the VB custom action? Something is making a call
to Setup.exe in the temp folder and I am running out of ideas :)

"Heather B." <heat...@NOSPAM.attglobal.net> wrote in message

news:3bb8de27$1...@news.installshield.com...

[James P. Hoffman]

What you've told me opens a world of options. This will let me do a serial
number check. Also, I could test whether Jet 4 is already installed before
deciding to run the distributable installation program from MS. Perhaps even
decide whether MDAC_typ is needed! I've been doing several installation
tasks in the login form for my application; but, I'd much rather have it in
a separate executable. Repair mode execution might a problem; but, should be
solvable.

Thank you very much!

Pete Hoffman

"Heather B." <heat...@NOSPAM.attglobal.net> wrote in message

news:3bb8e3b3$1...@news.installshield.com...

[Heather B.]

Repair mode is solved. If you add a separate custom action and select Run
During Uninstall for this action, the list of events changes to include the
repair mode events. I chose to run MDAC 'Before Settings Changes' and it
runs during repair mode. Unfortunately it also runs during uninstall, but
for me that's no problem. I also tried having it run 'After Maintenance
Welcome', but that caused my custom actions to run before the user even
selected whether they wanted to Change, Repair, and Remove my application,
and that felt a little strange to me when I tested it out.

Good luck...
Heather

"James P. Hoffman" <jpho...@velocenet.net> wrote in message

news:3bbb...@news.installshield.com...