3 replies to this topic

[Superfreak3]

Hi all,

We are going to be releasing our updated application soon, which now has a VC++ prerequisite. First off, we can't bootstrap our client side installer due to the update mechanism we use. It basically checks versions in .ini files on Clien and Server sides and launches the .msi if updated availability is detected. But I digress...

A year or so ago we had a similar situation. Our problem was that we had a Custom Action that relied on an earlier version of the runtime so it would blow up during install when Merge Modules were used to deploy VC++. I was told that at the time of Custom Action launch that the Module resources were not yet available. The action was sequenced after RegisterProduct/before InstallFinalize.

I think a commit custom action was suggested, but the problem was that the action ran in System Context and if used As a commit action, I no longer had the elevation, which would have to be supplied by the installing user. This didn't work in our processes because our Client installation must be silent.

Now to the present... like I said, we now need VC++ 2010. I have 3 or 4 actions (user context) that rely on the runtime. I've tested the install using Merge Modules and this time it seems to work! I can't understand why. Does InstallShield handle this or workaround this differently somehow? Our past installs were built with Wise, but at the time I was told the situation was due to Windows Installer limitations.

I then thought it might be the version of the Windows Installer engine. It worked on 4.5 so I tested on 3.0 to be sure and it worked there as well.

If it worked now, this would be great. It would sidestep the need to have end users update all of their workstations with VC++ before launching our installation.

Or, to be safe, since the involved current actions are user context, I wonder if I could use commit custom actions. I would still think this would be met with elevation prompts on >= Vista.

I also don't know if there are VC++ msi's available for a child or chained install, but this will rip out the runtime on uninstall, correct. I wouldn't want to do that and possibly jeopardize other applications.

Any help on whether I'm safe just going with my current actions sequenced as is (near end, but before InstallFinalize) with the use of Merge Modules would be greatly appreciated.

Thanks Much!!

[Stefan Krueger]

I'm not sure I fully understand what you are saying but: if your custom action depends on files which are installed by your setup, it must be scheduled after InstallFiles (and before InstallFinalize) and scheduled as "deferred in system context" (it can also be simply "deferred" if you don't need admin poermissions)

This article explains the scheduling options:
http://www.installsi...00108/index.htm

[Superfreak3]

Yes, the files that are executed as Custom Actions are part of the installation and the actions are scheduled after RegisterProduct. The .exes that are fired are dependent on the VCVC++ 2010 runtime, which is included via Merge Modules.

In the past, when I would try something like this, the actions would fail because I was told the runtime on which the .exe's depend, placed via merge module is not available until after the Install Finalize actions.

Now, I include the runtime via Merge Module and fire Custom Actions that depend on it prior to install finalize (after RegisterProduct) and it seems to work now. I tested on various versions of the Windows Installer engine and it worked across the board. I'm wondering what is different now. The only thing I can think of is that InstallShield does something to work around what I saw as a WI limitation (Merge Module resources not available for custom actions).

[Stefan Krueger]

I don't think that InstallShield is doing anything special here. There's no difference if a file or component is coming from a merge module or is in the main setup project.
There is a limitation however for .NET assemblies which are installed to the GAC. As far as I remember they are not available in the GAC until after InstallFinalize.
And of course if the merge module includes a custom action which is scheduled after InstalFinalize this could also be a problem.