Software Deployment

Have you tried adding the custom actions into the MSI directly using Orca instead of Wise?

No, but I'm curious as to what difference you might think that would make.

I'm guessing but this may be connected with modal/modeless dialog handling.

If the EXEs are yours, make sure the dialogs are modal. If they're not, I'm stumped, other than suggesting a major kludge, such as having the EXEs launched by a script which gets the handle of the app's window and forces it to the top of the Z order [shudder...]

Just speculation, but maybe wise has it's own code inserted into the MSI as a custom action that runs your customs action. Apart from that I would just use a process of elimination

Is there a problem with the way wise adds the custom action to the MSI?

Is there a problem with the way windows installer executes the custom action?

Is there a problem with the way the EXE are coded?

Can I fix the Code?

Can I find a work around?

maybe wise has it's own code inserted into the MSI as a custom action...thus making its MSIs totally incompatible with any other editor? I think not.Is there a problem with the way wise adds the custom action to the MSI? What other way do you imagine there is, than adding rows to the CustomAction and relevant execution tables?

...thus making its MSIs totally incompatible with any other editor? I think not....

Both Wise and InstallShield insert their own custom tables and custom actions into MSI's created by their products. This doesn't mean that MSI's are incompatible with other editors, in that they cannot be opened and edited it just means that if you open an MSI created by Wise with InstallShield, InstallShield doesn't know what to do with the custom tables or actions added by Wise.

In fact if you look at InstallShield, a lot of their MSI's require ISSCRIPT to be installed for the MSI to even install - Pretty non standard.

Anyway I was just speculating that maybe Wise inserted these "EXE's" into the MSI using the binary table and had it's own custom action the ran these "EXE's" and that I would check the MSI using Orca to make sure this wasn't the case before trying to get them recoded or find a work around. Considering the amount of junk both these products put into their MSI's, I don't think my suggestion was unreasonable.

Both Wise and InstallShield insert their own custom tables and custom actions into MSI's created by their products.....which they do by using standard MSI APIs. CAs are added to the CA table. Your original post implied that there was some magic way that Wise was adding CAs to the MSI and made no mention of custom tables. Quite what custom tables have to do with Custom Actions escapes me.In fact if you look at InstallShield, a lot of their MSI's require ISSCRIPT to be installed for the MSI to even install - Pretty non standard.So what? The requirement for ISSCRIPT is to execute function calls contained in the DLLs via Custom Actions - pretty standard.I was just speculating that maybe Wise inserted these "EXEs" into the MSI using the Binary table and had its own custom action the ran these "EXEs" How else would that work?!?

ORIGINAL: Superfreak3

During some testing on newer OSs --Win 7 and 2008 Server-- the .exe's fire, but their forms, message boxes, etc. are behind any displayed Windows Installer dialogs.


Thinking of workarounds, do you really need to display the Windows Installer dialogs given that the EXE dialogs are themselves a visible indication that an installation is in progress ?

If the Windows Installer dialogs are prompting for user input, this can be avoided using an appropriate response transform.

Have you tried the installation using the available silent switches to msiexec.exe, (for example /qn) to see if that makes a difference ?

Spartacus