0

I have a Custom Action that runs an executable within an msi installer package. The exe is compiled as a console application and stdouts necessary info.

  1. I want that output redirected to the MSI log file.
  2. I don't want the console to be shown during the installation.

For number 2 I suppose I can use windows as a subsystem, which will not open a console at all. But no output will be shown even if I run the exe from a terminal (PowerShell/CMD).

For number 1 I thought of running an executable as a subprocess called within a Custom Action DLL, but it is not possible since the exe is stored in a binary table and won't be generated when I need it. Moreover, it will have a random name.
The Custom Action's logic MUST be run as a separate process.

Sergey Kolesnik
  • 3,009
  • 1
  • 8
  • 28

1 Answers1

1

EDIT: Some colleagues wrote a free guide on installation testing. Maybe it will be useful in the future, to avoid such costly mistakes.

I don't think you can do it if you want to run the custom action as a separate process. I might be wrong. But I never tried this and it doesn't seem/sound possible.

Basically, the MSIEXEC process will own the handle of the log file created by the installation and I don't think you can share it with a separate process.

Why do you need to use a separate custom action process?

As a test - you could try to create an additional DLL custom action, that runs asynchronously. The purpose of this custom action is simply to communicate with your EXE process and write inside the log file any information you want to pass from the EXE custom action. I never tried this approach, but if you have time to kill and really need the main logic to remain in the EXE custom action, you could give it a try.

Bogdan Mitrache
  • 10,536
  • 19
  • 34
  • For details on why I must call a process see https://stackoverflow.com/q/70660365/9363996 – Sergey Kolesnik Jan 14 '22 at 13:46
  • an asynchronous dll might be a fine idea if I have multiple executables as custom actions. I'd run the dll in the beginning of the installation. But it is a hack) – Sergey Kolesnik Jan 14 '22 at 13:51
  • Damn, I remember when you posted the initial question. I guess you are stuck with the EXE custom action. – Bogdan Mitrache Jan 14 '22 at 13:51
  • I also though if it is possible to provide an exe entry point for a dll, so a custom action dll would start itself as an executable... Or somehow embed the executable – Sergey Kolesnik Jan 14 '22 at 13:55