Run solution exe after installtion using installshield

Question

I want to run my exe after installation using InstallShield. InstallShield completes the setup correctly but do not run the exe.

I found another way to add an exe in startup but it runs after restart. I would like it to run without restart.

Is it possible ?

Coonskin

what this have to do with asp.net ? – Staal

Nothing. Nor does it matter that the EXE is a C# application. Tags removed. It would also help to understand what version, edition and project type in InstallShield is being used. – Real

Answer 1

What version and edition of InstallShield are you using? Also what project type are you using? (InstallScript, InstallScript MSI, Basic MSI? )

Assuming Basic MSI, InstallShield has a built-in pattern to support this story:

1) Click on the Project Assistant Tab

2) Click on the Installation Interview Icon (Page)

3) Click Yes for "Do you want to give the users the option to launch your application when the installation completes?

4) Click the browse button to select the EXE that should be the target of the operation.

By default the checkbox (launch program) on the setup complete dialog will not be selected. To select it automatically add the property LAUNCHPROGRAM to the property table and set it to a value of '1'.

Real

I followed these steps and my app is launched. However the UI is not displaying. But if I click on the short cut on desktop the UI appears.I dont know what I am missing as I am new to this. – Nudd

I'm guessing your application is sensitive to working directory and that it's being provided by your shortcut. – Real

Answer 2

Christopher Painter's answer will work for you most of the time. Those are the initial steps to take, but there are some additional details if you find that isn't enough. For instance, skb reported that this didn't work for him. I found that I was in the same boat (even though I've built a dozen other installers which had this work!).

1. Follow Christopher Painter's instructions.
2. Click on the "Installation Designer" tab. Within "User Interface" select "Dialogs".
3. Within "All Dialogs", expand "SetupCompleteSuccess", and select "Behavior".
4. Select the "Ok" push button control. Then, select "Events". (look to the bottom of the screen where it says Events/Subscriptions/Conditions)
5. You should have a "DoAction" event, with an "argument" equal to "IS_LAUNCH_MY_PROGRAM_PLEASE" and a "condition" of "LAUNCHPROGRAM". If not - add that. "LAUNCHPROGRAM" refers to the property of that name. It will have a value of 1 if the launch checkbox is selected, and thus meet this condition. IS_LAUNCH_MY_PROGRAM_PLEASE refers to the Custom Action which is launched. If you want, you can change that CA here to make any custom action fire instead. I opted to leave this alone, but replace the CA with one of my own.
6. Open your list of Custom Actions (Behavior and logic... Custom actions and sequences). You should find a CA there named IS_LAUNCH_MY_PROGRAM_PLEASE. Delete it!
7. Add your own IS_LAUNCH_MY_PROGRAM_PLEASE CA. Right-click "Custom Action" (the list header) and select the type of CA you want - or launch the wizard. Just be sure to name it "IS_LAUNCH_MY_PROGRAM_PLEASE" if you left the dialog behavior as it defaults.
8. To launch an exe - with the WORKING DIRECTORY changed (which was the reason my app wouldn't appear, and apparently skb's as well based on the comments) Select "New EXE"..."Path referencing a directory". Change "Return processing" to "Asynchronous (no wait for completion)". Note the "MSI type number" becomes 226. Set the "Working directory" to INSTALLDIR(assuming the program you want to launch should be found in your new program's directory). Set "Filename & command line" to [INSTALLDIR]YourApp.exe.

Nernst

Alternatively, one could just fix their app to not be working directory sensitive. – Real

That's true... But that's not necessarily quicker and easier. There's a good reason setting a working directory is a virtually universal trait for anything that launches other processes, and why there is an option for that in IS as well. Redesigning your program's ability to resolve relative paths, in order to appease the installer? That seems backwards. Other installers usually make this trivial. You should not have tight coupling to your installer. – Nernst

I would argue that having the installer patch around an application defect is backwards. Having the installer set the working directory IS tight coupling. And it probably is quicker and easier because the developer asking the question likely understands his application better then he does his installer. – Real

Touché... "Defect" is a bit strong here to describe the issue. "Limitation" or "weakness" is better. I certainly don't disagree that it's better to have an application work perfectly from any directory. Sometimes that's a bit of hassle to pull off though, and sometimes you build installers for other people's program's - or have third party scripts / binaries etc. for which you have zero control over. Having the ability to set the working directory is important. I've outlined how to do it here, and it only takes a few minutes. – Nernst

Sorry, I'm old school in my vocabulary. I say "fail" not "pivot". Yes. My approach with an in-house team at my day job and my approach with an outside client may vary. I will try to advise them both to do the right thing though. As a .NET developer I know the kinds of incorrect assumptions that can be made in code here and the best practices to avoid those. One common problem is a developer who doesn't understand the working directory of a windows service is [SystemFolder]. There's no way to work around that in an installer. – Real