Hi All,

Here's my latest scenario/predicament...

We have a 32 bit installation that now has to install some 64 bit parts. I don't have a problem there as the pieces are placed properly based on architecture.

Now, one of these 64 bit pieces is a third party PDF printer driver installer (.exe) that depends on the VC++ 2008 SP1 Runtime, which I'm installing via Merge Modules. However there is problem here in that the Merge Module resources are not available to be properly utilized by the Custom Action that fires the driver installer. This situation is similar to this.. VC++ Runtime and Custom Action Dependency

I've tried everything to sidestep this issue: Use the vc-redist .exe from Microsoft (Can't fire from my install because two Windows Installer processes would be running at the same time.), Nested .msi from main install (I can't even get this to fire properly.), etc.

I'm wondering if I can somehow utilize a Commit Custom Action to run if VersionNT64. I'm seeing this as a potential problem as I need everything to be silent with no user interaction. I think when the pdf driver installer is fired on Windows 7, for example, elevation will be required.

This is a challenging one for me. I don't know that I'll be able to pull this one off so end users running 64 bit systems might just have to ensure they have it first.

Any ideas would be greatly appreciated!

Thanks Much
0 Comments   [ + ] Show Comments

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.

Answers

0
How are you deploying? An SCCM/SMS "package" could push this out with VCRT as a pre-requisite, as could judiciously linked GPOs. The latter is how dependencies were dealt with at my last client.
Answered 08/23/2010 by: VBScab
Red Belt

Please log in to comment
0
There are some that use third party deployment means, but unfortunately, we have our own update mechanism which basically checks versions in .ini files and fires off the .msi if update needed. A lot of our smaller clients use our update scheme. I am currently trying to get away from supporting this since its getting harder to maintain due to more stringent security, but I digress.

Here's where I'm at after additional tinkering... I have created the VC++ redist .msi by firing the .exe, grabbing the .msi and .cab, stream the .cab into .msi with msidb.exe and changing media table to indicate internal cab (#).

Now, using Wise Installation Studio, I've scheduled a run MSI from installation Custom action that is sequenced after InstallFinalize in the Execute Immediate sequence. This seems to work OK as the PDF installer will run if manually fired off after the installation for testing purposes (making sure VC++ runtime is actually in place).

Now, my problem is that firing the PDF installer will no longer be elevated because its needed after the runtime install which is now after InstallFinalize. Unfortunately, it is highly desirable to have this all silent, which in this instance will not be the case.

I'm in a difficult situation here I'm afraid. It would be cool if I could simply install the runtime requirement and fire off the pdf installer while elevated (in system context) under our main install. It just seems that this cannot be done at this point.

Thanks for the reply by the way!!
Answered 08/23/2010 by: Superfreak3
Black Belt

Please log in to comment
0
My motto (well, one of them, anyway) is: avoid complication where possible. Since you're using WIS, is creating an EXE - which installs VCRT followed by your app- out of the question?
Answered 08/24/2010 by: VBScab
Red Belt

Please log in to comment
0
Unfortunately yes. Our automated update mechanism looks for an launches problematicapp.msi if an update is needed. There's nothing coded for handling prerequisites, at least not yet.
Answered 08/24/2010 by: Superfreak3
Black Belt

Please log in to comment
0
Clearly, whoever designed that system wasn't a packager! :-)

I'm out of ideas, I'm afraid, but I will cogitate further.
Answered 08/24/2010 by: VBScab
Red Belt

Please log in to comment
0
Its not that the auto updater is a bad thing its just the company has become totally reliant upon it. No matter what, end user IT departments are going to have to get involved at some point. I think this is one of those times.
Answered 08/24/2010 by: Superfreak3
Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity