1

I am working with InstallShield 2018. I’m trying to get the installer to execute a program (with some command line parameters) at the end of the installation. When the installation gets to the point where the program should be run, I get the message: “There is a problem with this Windows Installer package. A program required for this install to complete could not be run.” (with some more details – see below)

The program that I am trying to execute was developed by ourselves using C#, and requires admin rights to run. It has an (integrated) manifest file to enforce this. I am currently installing it with a merge module because this program should be re-usable between different software versions.

To accomplish this I’ve added a “Deferred execution in system context” custom action (type 3682) right before “InstallFinalize” with condition “NOT REMOVE”. I’ve created an entry in the directory table that points to the installation folder of the executable, with the source of the custom action pointing to that entry, and the target being the name of the executable and the command line parameters, i.e.: VersionManager.exe /Register "[ProductName]" /loglevel info

Return processing is set to “Synchronous [Check exit code]”. I’ve tried setting it to ignore the exit code – this works to the extent that the installation seems to complete without problems, but when I examine the log file it has been unable to run the program and I see something like this:

MSI (s) (F0:0C) [10:09:49:724]: Executing op: CustomActionSchedule(Action=RegisterAfterInstall,ActionType=1122,Source=C:\Companyname\VersionManager\,Target=VersionManager.exe /Register "Fully parsed product name" /loglevel info,)
MSI (s) (F0:0C) [10:09:49:740]: Note: 1: 1721 2: RegisterAfterInstall 3: C:\Companyname\VersionManager\ 4: VersionManager.exe /Register "Fully parsed product name" /loglevel info 
Info 1721.There is a problem with this Windows Installer package. A program required for this install to complete could not be run. Contact your support personnel or package vendor. Action: RegisterAfterInstall, location: C:\ Companyname\VersionManager\, command:VersionManager.exe /Register "Fully parsed product name" /loglevel info

When I run the given command in the specified location (with admin rights) the installation appears to complete without problems. The only thing I can think of is that somehow the program isn't being executed with admin rights.

When I check the drive the moment the message pops up (when checking the exit code), the files are actually present on the system (I had a problem with that earlier, it produced a different error message).

I found a post somewhere that suggested changing the action type to “Commit execution in system context” (because the program depends on .NET stuff registered in the GAC and that is apparently inaccessible before installfinalize is finished) but that did not help.

I’m not at liberty to share my source code (or at least not all of it), but if the information above is insufficient I may be able to set up a small example project that demonstrates the same problem.

EDIT:

Although I'm still curious why the approach above is not working, I managed to find a workaround. If I include the files of the program directly (instead of via a merge module) and I define a custom action of type 3602 (i.e. "installed with product") it works fine. I didn't try this earlier because I had my mind on getting this working with a merge module. (I'm aware that it would be possible to define a custom action in the merge module, but then I cannot fine tune the command line parameters)

I still do not fully understand why, though.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
MHJF
  • 127
  • 8
  • What is this EXE doing? Dependencies to the GAC is a legendary problem for managed code due to the [conflicting commit models of Fusion (GAC) and MSI](https://blogs.msdn.microsoft.com/astebner/2005/03/10/dont-use-managed-code-to-write-your-custom-actions/#comment-345). You should not have such dependencies for custom actions at all (which is why I prefer statically linked C++ dll custom actions - [minimal dependencies](https://stackoverflow.com/a/37402/129130)). WiX allows you to bundle all dependencies in the same native CA dll [as described here](https://stackoverflow.com/a/52320995/129130). – Stein Åsmul Oct 20 '18 at 11:00
  • Sorry for the late reply; I didn't really manage to make progress with this and got swamped by other issues. The EXE basically manages different versions of the software installed on the same machine; it's main purpose is to manage registry entries. It all has to be backwards compatible and there's 20 years of history, bad practices etc. involved, so we developed a custom program to manage all registry entries rather than have the installer try to take care of it. – MHJF Nov 13 '18 at 08:09

2 Answers2

0

It looks to me like the file you are running didn't have the necessary dependencies. If you run a dll for example and place it in the binary table, then that dll has to have no dependencies. If you point to a dll installed with the product, then any necessary dependencies should exist in that same folder.
There are of course workarounds to this, but a limitation to installing with the product is where you can place it in the sequence as you have to wait for your stuff to be installed before running the custom action.

Bill
  • 132
  • 1
  • 1
  • 10
  • The file does have a number of dependencies - but as far as I can determine they are all correctly installed and present at the time the call is made. I'm not executing from the binary table (unless I'm sorely mistaken about the action type) - does that restriction apply to any of the other types for running an executable? – MHJF Oct 17 '18 at 08:30
0

There's not really enough info to debug this because it's basically your program failing. Some of the problems tend to be:

  1. That code is running with the local system account, and that means access to some commonly-user items won't work. Attempts to use HKCU, and any user folders (such as User's Application Data Folder) or mapped network drives will be unpredictable and cause a crash.

  2. The program isn't being run from Windows Explorer so the current working directory won't be set. The path to your files will need to be explicitly specified (and this may be why "run from installed location" works).

You usually don't need to do registration at install time. The information is nearly always static and can be extracted at build time into (for example) the Registry table of the MSI file. InstallShield probably has something for this, a registration setting of some kind.

PhilDW
  • 20,260
  • 1
  • 18
  • 28
  • Sounds like a [GAC dependency issue](https://blogs.msdn.microsoft.com/astebner/2005/03/10/dont-use-managed-code-to-write-your-custom-actions/#comment-345)? Or a general dependency issue? Wondering if wrapping with the [WiX MakeSfxCA.exe](https://stackoverflow.com/a/52320995/129130) would solve the problem? In either case, as I comment above these managed code custom actions are loose cannons for all to see I think. Runtime issues, dependency issues, version interference, etc... And God help us with Powershell now hitting the mix. I wonder - like you do - what that executable is actually doing. – Stein Åsmul Oct 20 '18 at 11:07
  • Have you ever tried wrapping the GAC dependencies within the CA dll made by MakeSfxCA.exe? Would that work, or could you risk loading older versions from the GAC - if present? Should be OK if version is different? I am no good at managed code. Always unsure, and I hate it enough to not test it. So why not pick Phil's brain? :-) – Stein Åsmul Oct 20 '18 at 11:11
  • To analyze the problem, I added some trace logging to the very start of the program - it doesn't execute (unless it's the logging itself that fails); at these point, there have been no attempts to do anything with HKCU, user folders or the working directory. I'm looking at the WiX MakeSfxGA but I don't fully understand what it does - is this basically a way to wrap all dependencies inside the executable itself? – MHJF Nov 13 '18 at 08:24