View Full Version : Custom Action, launch exectuable from source CD

12-05-2002, 03:56 PM
This should be easy, but I'm having trouble referring to the source drive of my distributed setup.exe to launch a custom action after installation is complete.

Here's the situation. I have an .EXE file that will be distributed on my installation CD along with the setup.exe file I create with InstallShield. I want to execute my custom .EXE file once installation is complete.

I have set up a Custom Action, specifying that the file exists on the target computer (at least it will, on the CD). Unfortunately I don't know the CD drive letter the user will be installing from (likely D:, but maybe not), so I can't enter a physical file location.

Is there a way to refer to the source media identifier that the user ran the setup.exe from? I have found references to "Disk1" files, the [SUPPORTDIR] directory in the file view, and various programming identifiers such as "srcdir", "setupexepath", and others, but can't get the seemingly simple process of chaining to an outside program on the installation media.

I can't put my custom .EXE file in my installable file set, because it specifically needs to run from the installation media -- or at very least, needs to know the path to the installation media.


12-06-2002, 12:27 PM
Let's cheat a little.

1. Create a new root level feature in your project
2. Set it's "Visible" property to "Not Visible"
3. Set it's "Remote Installation" property to "Favor Source"
4. Associate this feature with all Setup Types
5. Add the file you want left on the CD to this feature
6. Create an Exe Custom Action that "Runs a file installed with the product" and select this file.
7. Sequence to launch after "Setup Complete Success" dialog (only option available)
8. Build and install

This should NOT install this file locally and SHOULD run the exe as a custom action from the disk. Give it a try and let me know if it works.

If this doesn't, try the following:
1. Put this file in the "Disk1" node
2. Create an Exe custom action that runs a file on the target
3. Set the Custom Action's "Folder name" property to "[SourceDir]"
4. Set the "FileName" property to the name of your exe
5. Build UNCOMPRESSED and install

12-10-2002, 11:05 AM
Thanks, for your response, Chandima. Unfortunately, for various reasons, building uncompressed is not an option for this particular project. And it seems that both suggestions seem to require it. Is there no variable or symbolic that refers to the path that the SETUP.EXE was originally invoked from?



12-10-2002, 12:08 PM
I'm afraid not. The Windows Installer only cares about the msi file. Setup.exe is an InstallShield wrapper that installs the windows installer and .NET framework engines.

You could try launching the exe through another Custom Action though. I am a little familiar with VBScript so I can point you in a possible direction. Try running the following VBScript as a Custom Action with your compressed build:

Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
MsgBox WshShell.CurrentDirectory

Does it give the path to where Setup.exe is or where the msi is?

12-10-2002, 03:31 PM
Thanks for your quick replies, Chandima, I will try that. My only concern is that we can't be sure that the client computer has VBScript installed. I'll work on it.


02-05-2003, 05:01 PM
I think I have a similar question, so I post it in this thread.

I also need to know the sourcedir that the installation is from.
My application needs beside the MSI the .NET framework installed.
If I compress my application in a single .msi file the retrieving of the sourcedir works fine. If however one of the items above need to be installed first then I would need a setup.exe. The setup as we know places the .msi in a directory local to the user (which by the way creates different problems in e.g. an XP environment where different users need the program).

The solution I have come up with so far is to create a 'pre-requisite setup' this setup is a setup.exe that installs a dummy textfile in the temporary directory. After that one has been run manually I know the MSI and .NET framework are installed and I can safely run the .msi setup file.

Now wouldn't it be great if I could spare the installer/user the trouble of having to decide whether to run the setup.exe first or not, and combine the lot in one setup.

Would anyone have a suggestion on how to do that? I have thought of running the msiexec after the setup.exe is installed but then I need the sourcedir to find the .msi that I want to install :rolleyes:

Any ideas are appreciated.


02-05-2003, 06:29 PM
Is building uncompressed not an option? If it is an option the 'SourceDir" property will contain the path to the installer.

02-06-2003, 04:17 AM
Not really I think. The thing is that with the server install we create a distribution directory and a setup directory on the server. I want to save some shared configuration information (like what database to use with what credentials etc) in the distribution path.
In the setup directory needs to be the installfile.msi or, in the problem situation, the setup.exe.
To keep the the network environment neat, clean and tidy we want to keep a single install file there. We don't want to call out the wrath of the administrators :D .
So we strongly prefer the the use of one simple setup file.

The server setup can be uncompressed on a CD, no problem, but not the client setup. And this is where I need the SourceDir, to find the shared configuration file.
And I don't mind if there are a setup.exe and an installfile.msi on the server (I am sure I can sell this to my customers). I would prefer then for the setup.exe to automatically call upon the installfile.msi.

If it doesn't work out I will go with the to seperate files to be run individually. I think that if the MSI or the .NET framework needs to be installed it needs to reboot anyway (doesn't ir?). So I guess if that is the case I can sell that to the customers :) .



02-06-2003, 05:39 PM
I'm afraid I am out of suggestions here. Getting the path to the location of Setup.exe has always been an issue and I still haven't come across a neat workaround. Sorry :(.