Phil, Bryan,
Thanks for the response, I like Phil's idea the most, these are new files
that we are dealing with in internal test builds, so adding empty files will
do the trick.
Glad we found this before publicly deploying.
Marc
-Original Message-
From: Bryan Wolf [mailto:brw...@jackhe
Files are copied as part of an atomic step. Technically they are staged
somewhere during the copy but it's nothing you could meaningfully interact
with. There is no "OnFileCopy" type functionality, either.
Is there a reason you couldn't run the unlock CA before InstallFiles and just
attempt to
The file install occurs too late for your purposes. You'd need to have what
you need in the Binary Table and then stream the executable files to a
temporary location from which you could build a path/command line and run it.
--
John Merryweather Cooper
Build & Install Engineer - ESA
Jack Henry
I have a situation where on install a file in my msi may be in use on
upgrades. I have a custom action that will get rid of any lock on the
file. however this custom action has to be run as a 64bit process which it
does now.
so I need to run the custom 64bit exe file during install before copyin
Yeah - generally speaking most people shuffle installation architecture so late
in the process they've already implicitly handed off ownership to the installer
and there's nothing you can do. Same with deploying the databases, etc.
But I can dream of a day...
-Original Message-
From: P
You're saying that the application generates the files, so they are
already the property of the app's code so maybe a CA is the better
solution rather than trying to hand them over to Windows to deal with.
Transferring ownership is often a problem.
Assuming I understand the issue: I would make emp
You could also schedule the RemoveExistingProducts action later in the
sequence. You lose several advantages of major upgrades and pretty much
absolutely have to follow component rules closely as if it were a minor/small
upgrade but it is an alternative to the preserve & restore pattern.
Altern
Thanks for the reply. I thought that was to decide if it should be
uninstalled only. Making this false works.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/ExePackage-InstallCondition-evaluates-to-true-but-it-is-not-installed-tp7594184p7594187.
Hello Everyone,
I found tons of answers to this problem, but I have a hard time believing
that CA's are the best way to resolve this. I am far from being a WIX
expert so I would appreciate a second opinion on this one.
I have an application that generates configuration files during executi
Because the DetectCondition is also true, which you can tell by "state:
Present". It won't try to install it if it thinks it's already installed.
On Thu, Apr 17, 2014 at 8:16 AM, darbid wrote:
> In my bootstrapper chain I have as an exepackage the VSTO runtime.
>
> Installed is version 10.0.4X
In my bootstrapper chain I have as an exepackage the VSTO runtime.
Installed is version 10.0.4 something and there is a newer version.
As you can see the install condition is evaluating correctly to true so why
is it not installing it?
--
View this message in context:
http://windows
I would give the two bundles a different Bundle/@UpgradeCode (using and $(var.UpgradeCode) ), and then add a Util:ProductSearch for the
other UpgradeCode. (Or rather than the Util:ProductSearch implement the
detect the other bundle in the BA with BAFunctions.dll, or in an mba.) If
you want to ke
12 matches
Mail list logo
