Its true.
But in this case we want this component(file not getting patched) to follow a
parent which is getting patched. You need to try this and do a thorough testing
of all the scenarios.
There is also a other way of tackling this situation, the point is the value in
file version field(in
Hi Jacob, That is what I had tried but I get the error that InstallFiles is
a duplicate primary key.
-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com]
Sent: 16 October 2012 16:51
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users]
Have you anything referencing the fragment that the installexecutesequence is
in ? There is no installexecutesequenceRef element so you'll need some way to
tell Wix to include the new sequence in the patch.
-Original Message-
From: abhijit chakraborty [mailto:abhi.chak.ju...@gmail.com]
I have a few custom actions that run just before InstallFinalize and I am
trying to tidy up my progress bar because at the moment it runs two or three
times and looks empty just before the install completes. They are immediate
custom actions and I have used ProgressText to show text explaining
RemoveFile table entries are always associated with a component
http://msdn.microsoft.com/library/aa371201.aspx If you removed the RemoveFile
table, you would be changing component contents, which is not allowed.
You could possibly add a condition of NOT PATCH on the RemoveFiles action so
that it
You ultimately have to call MsiProcessMessage. The Wix SDK might have some
useful functions to make that easier. Scheduling a deferred CA with
WcaDoDeferredAction from the Wix SDK is easy because it allows you to specify
the ticks as its 3rd parameter. There might be an equivalent for immediate
Thanks Peter, I get 4 properties from my MSI in my custom action so that is
why it is immediate. Am I correct in thinking you cannot get properties in
deferred custom actions?
-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: 17 October 2012 11:27
To: General
You have to pass properties to deferred CAs in a particular way. Effectively,
you concatenate their string values together, with some unique separator,
into a property with the same name as your custom action. In the CA you read
that property and parse the values back out. Again there are some wix
Thanks for all that info Peter, had a quick read and immediate custom
actions is fine for what I want to do, now just to get them implemented in
the progress bar. Also my progress bar fills completely and then resets for
copying the files over, I have looked at my log and I can't seem to find
what
I had added a dummy property in the ddp file like
*Product ...*
*Property Id=DummyProperty Value='1' /*
*InstallExecuteSequence*
**
**
*/InstallExecuteSequence*
*/Product*
and added a PropertyRef for the dummy property in the patch.
I saw that the new dummy property
The standard progress messages sent by windows installer cause this. There
is, at minimum, one bar for the preparation of the script and then a reset
and then another for the execution of the script. You can also have roll back
and possibly some other circumstances in which the bars don't just
Your code snippet shows the right way to proceed.
If you can see the property change but not the sequence change, it might be
because the property and sequence are in different fragments.
Are you using admin installations, rather than wixpdbs, to build your patch ?
If so, the MSI is automatically
*I think to get around that, you would need to add CustomActionRefs for any
action whose order (sequence
number) has changed.*
**
Can we add custom action refs for predefined actions?
In InstallExecuteSequence we are changing the conditon for
*ScheduleReboot*action.
Regards
Abhijit
-Original
I've never tried it, but I'd expect so.
-Original Message-
From: abhijit chakraborty [mailto:abhi.chak.ju...@gmail.com]
Sent: 17 October 2012 14:27
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] FW: FW: FW: Patch installation asks for a reboot
*I think to get around that,
Hi,
I have Patch installation that removes RemoveFile table. The patch can be
installed without any problem. Problem begins with the second patch that
also missing RemoveFile table: it can be installed alone but both patches
cannot be installed on target product in any sequence.
The question is:
Util:CloseApplication is the Wix way to do it. I've provided an example on
this thread
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/CloseApplicatio
n-td6885610.html#none
Also, you can document the requirement or put it in a bootstrapper/chainer.
-Original Message-
Hi Peter,
thanks for kindly getting back to will checkout the thread.
Ta.
On Wed, Oct 17, 2012 at 5:01 PM, Peter Shirtcliffe pshirtcli...@sdl.com wrote:
Util:CloseApplication is the Wix way to do it. I've provided an example on
this thread
I am trying to close Outlook since our product is a add-in for outlook, the
uninstall brings the FileInUseProcess which is great, but I also want this
for the INSTALL
I am doing this but it is not working:
util:CloseApplication Id=CloseMicrosoftOutlook
Property=FileInUseProcess
I am trying to close Outlook since our product is a add-in for outlook, the
uninstall brings the FileInUseProcess which is great, but I also want this
for the INSTALLI am doing this but it is not working: CA:
Setting file in use process...Any suggestions?Steve
In Vista and above the restart manager closes the app:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa373651%28v=vs.85%29.aspx.
That is what I use. For Windows XP I have a custom action that closes my app
although it looks like I should use Util:CloseApplication.
There was a
I don't think you can make the filesinuse dialog appear without trying to
replace a file in use. Why not close Outlook for the user with
CloseMessage=yes ?
-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com]
Sent: 17 October 2012 16:21
To: wix-users@lists.sourceforge.net
Hi All,
I have setup my MSI so that it detects when a newer (higher version) is
installed. This works fine from a human interface point of view (i.e. I get a
message saying that a later version is already installed). However when
another product tries to install my MSI they are expecting to
Error 1638 isn't related to anything you do internally by denying certain
installs for your own internal reasons. It's returned when the install
cannot even proceed because you're trying to install a package with the same
ProductCode (or PackageCode) as one that's already installed, but with a
The devil is in the details. A verbose log is the best way to see exactly
what's going on. For example, if Windows already knows that it will need to
reboot at the end of the install then it won't bother prompting to close
down any apps. What's the point?
Phil
-Original Message-
From:
You can write a custom action that uses the MsiProcessMessage (or
equivalent) call with INSTALLMESSAGE_FILESINUSE to cause a FilesInUse dialog
to display, as long as you populate the required record in the right way.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371614(v=vs.85).as
px
Hey all,
I'm struggle a bit with 3.6.
In my build process via MSBuild (vs2010) I'm now getting the following
error:
light.exe : error LGHT0001: Illegal characters in path.
Exception Type: System.ArgumentException
Stack Trace:
at System.IO.Path.CheckInvalidPathChars(String path)
Hello,
I would like to start using the bundle self-update feature introduced
in WiX 3.7 in our installer. Since this is work in progress and the
feature is not much documented yet (or am I wrong?) I have several
questions.
So far I found that the bundle wxs should contain the Update element
Email Disclaimerhttp://www.redprairie.com/Content.aspx?id=2471
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Hi Phil,
I am not sure that I understand.
The scenario is that I am trying to install the same product as one that is
already installed but with a different version (i.e. I am trying to install an
older version of the same product, and I am looking to provide a way to fail
gracefully).
The general behavior is that Windows will return the error result
appropriate for the situation, and it decides internally, and it's nothing
to do with any of the ways you might use inside the MSI to say that you
don't want the install to proceed, once it has got through the Windows
checks and
30 matches
Mail list logo
