Video Screencast Help

Calling an msi from msi

Created: 09 Aug 2009 • Updated: 21 May 2010 | 13 comments

Normal
0

false
false
false

MicrosoftInternetExplorer4

hello,
I'm using wise for windows installer version 6.10.0.450, and I have the following problem:
I have an msi installation that I have created using wise, and im trying to call another msi installation. Although I can compile my msi, during runtime windows cannot run the nested msi so I am currently using an outer file that runs all additional msi application required.

I have tried "install msi from destination\installation" in msi script.  
Is there a way to do this from wise? Perhaps a more updated version of wise installer could solve this problem or another elegant solution?

And another question: is there a way so wise can check previously installed versions of those msi I need to add to my installation? msi that I have and have not written.

Discussion Filed Under:

Comments 13 CommentsJump to latest comment

philbenson's picture

MSI installations is a path you should not go down. Even though the windows installer 4.5 now supports nested installations correctly, I have heard (I think Ian if he is reading this would point out a few blogs / links) that even this is a little more than "adventurous" to say the least. Rather than calling nested installations, create a wrapper (be it in Wise Script or VBS, I prefer VBS) to install both MSI's. Using the MSI SDK from VBS, you could determine if the "pre-requisite MSI package is installed, if not then install it first before installing the main MSI package.
Just my tuppence

Cheers
Phil

nac's picture

In wise script you can call MSI one after the other directly it works fine. keep in mind sequence of installation.

There is no direct check you can use system search from wise script to check if previous version is installed in registry (currentversion\unisntall\{ProductCode}).

in wise script you can use "Get registry information from" and specify registry path to uninstall\{Productcode} key in HKLM.

If registry is present that means previous version is installed.

VBScab's picture

> If registry is present that means previous version is installed
Too big a jump in logic there for me. I'd want more than a registry key. And of course I *know* that that's all WI uses but I can't control that. I'd set up a check for a) the uninstall string, b) some registry key/value which the app uses AND c) the application's main executable or DLL. I may even be persuaded to check that file's version details, too.

Paranoid? Me?

Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.

philbenson's picture

have you got the links to that Blog / Website about that guys adventures with nested msi's in 4.5? Or perhaps a link to the forum entry where you made wrote the links?

Cheers
Phil

VBScab's picture

[woosh]Straight over my head, I'm afraid. Have I posted links re: v4.5 before? Perhaps it was on AppDeploy...sorry, grey cells are disappearing faster than I can replace them these days :(

Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.

philbenson's picture

but I remember a link to a blog about the very subject, as yours, my grey jelly is'nt as effective as it once was ;-)

Cheers
Phil

VBScab's picture

Ahhh....I'll bet that was John McFadyen's blog on LiveSpace. Check AppDeploy - it's posted all the place there!

Don't know why 'x' happened? Want to know why 'y' happened? Use ProcMon and it will tell you.
Think about using http://www.google.com before posting.

philbenson's picture

I have John's LiveSpace blog as a shortcut, and "drive-by" every now and then. I'm pretty sure it was from you??? Maybe EdT... ah well, have to look myself.

Cheers
Phil

EdT's picture

Running on borrowed grey cell.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

dudu's picture

hello and thank you all for your response.

Ive tried running MSI one after the other in execute immediate after install finalize,  but that failed. any other options to do that?

EdT's picture

You cannot run other MSI in InstallExecute sequence unless they are installed using one of the nested custom action types.

If you ARE using a nested custom action type, make sure that the path to the MSI you are trying to run is correct. If your main MSI contains internal compressed cab files, then the MSI will be uncompressed into a local temp folder and run from there. So if your call to another MSI assumes it is running from your source media location, it is bound to fail. The [OriginalDatabase] property holds the full path to the original source MSI that was executed - you can parse this to get the location of the other MSIs if they are in the same folder.

The only option for calling MSI installs from another MSI, without using nested custom actions, is to run the MSI installs from the InstallUI sequence. Vendor programs such as Autocad run their dependency installs this way. One thing you must note however, is that installing MSI files from the InstallUI sequence does not work if you perform a silent install, as during a silent install, the UI sequence does not get run at all.

So the best solution is the one that was offered to you at the beginning of this thread - use a wrapper script, eg a Wisescript, to call each MSI in turn. Since your wrapper script is not an MSI, you don't get any of the issues with install conflicts, and nested dependencies, that you get through the approach you are trying to implement.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

dudu's picture

Hello EdT and thank you for  elaborated reply.

I have several question:
1. Can I use custom actions types from wise, and if so how, otherwise where do I update the costumAction Table?

2. I thought of a solution of wrapping all the MSI's in an exe file. Can you tell me what you think is preferred in this case? how an exe is different in this regard from wisescript?

EdT's picture

1. The custom action types provided by Wise are those that are natively supported by Windows Installer. You can find a full description of each custom action type in the help file  MSI.CHM which is installed by Wise. In table terms, the custom action table is a list of all the custom actions used in the install. The custom actions in this table are called in the Install Sequences (UI and/or Execute) and the Execute sequence actions are run in sequence order. Once again, you can read more about the tables in the MSI.CHM help file.

2. Wisescript can be compiled to EXE assuming you have one of the "Studio" tools, but that function is not provided in WFWI 6.x other than for the single purpose of compiled an MSI into an EXE.

If you are sufficiently experienced in Wisescript coding, you could add your other MSIs as pre-requisites and then check that the wisescript stub code is correctly configured for installing these MSI files. That would give you a single EXE install with all the MSI files compressed internally.

If you have not done this before, I suggest creating a couple of simple test MSI files and experimenting.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.