Commit Custom Action Question(s)
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
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
Answers (6)
Please log in to answer
Posted by:
anonymous_9363
14 years ago
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?
Posted by:
Superfreak3
14 years ago
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.
Posted by:
anonymous_9363
14 years ago
Clearly, whoever designed that system wasn't a packager! :-)
I'm out of ideas, I'm afraid, but I will cogitate further.
I'm out of ideas, I'm afraid, but I will cogitate further.
Posted by:
Superfreak3
14 years ago
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.
Posted by:
anonymous_9363
14 years ago
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.
Posted by:
Superfreak3
14 years ago
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!!
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!!
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.