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 Client 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!!
0 Comments   [ - ] Hide Comments


Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
Answer this question or Comment on this question for clarity


The action was sequenced after RegisterProduct/before InstallFinalize

In Immediate or Deferred context?
Answered 02/07/2011 by: pjgeutjens
Red Belt

Please log in to comment
IMV, the C++ runtimes belong - in order of preference - in the build, your workstation update process or in a separate deployment as a pre-requisite by a deployment system. If you're distributing to clients, I'd suggest building a wrapper EXE to install the r/t first, check to see that it got installed before progressing on to your package.

If your update mechanism is preventing the w/s update route, I'd suggest that it is the former which needs work! :-)
Answered 02/07/2011 by: VBScab
Red Belt

Please log in to comment
Oh, I agree, our update mechanism needs work. It needs to be blown up!

However, we can't go the .exe route at this time.

That Action was Deferred for the previous reply by the way.
Answered 02/07/2011 by: Superfreak3
Second Degree Black Belt

Please log in to comment