Hi,
I have a Main installer(*.msi) which is around 200 mb(6000+ files)
Am using Wix Patch creation method for creating minor patches(using
msimsp.exe and patchwiz.dll method)
Should i include all the 6000+ files in my upgrade image or just only
files which are changed and which should be patched
ok, thanks for all your help
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Wix-Patching-tp7579825p7579841.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Sent: 14 August 2012 14:00
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Wix Patching
Hi Peter
That appears to do the trick, thanks. I can't add conditions to the custom
actions but if I add this to my patch it doesn't apply any of the config
modification steps:
Hi Peter
That appears to do the trick, thanks. I can't add conditions to the custom
actions but if I add this to my patch it doesn't apply any of the config
modification steps:
So - it must be one of the deferred custom actions... I will need to do
some further tests but its looking g
Yes, that's what I suspect.
The properties are declared in a CustomTable as follows;
SP_property_name
our_value
0
(as opposed to the usual elements. I think one of the custom
actions is resposible for copying these values in.)
We then reference these in wi
raymond.bo...@gmail.com]
Sent: 14 August 2012 12:41
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Wix Patching
Hi Peter, thanks for your prompt reply.
i will explore the options you've suggested and see how that goes.
Regarding whether the properties are persisted - not sure if I f
Hi Peter, thanks for your prompt reply.
i will explore the options you've suggested and see how that goes.
Regarding whether the properties are persisted - not sure if I fully
understand but basically the properties are held in a custom table and are
then either injected to Xmlfiles (e.g. web.con
Actions element under the patch element
as a more heavy-handed way of preventing any CAs from running. It depends on
what your CAs do.
-Original Message-
From: Raymond Booth [mailto:raymond.bo...@gmail.com]
Sent: 14 August 2012 11:02
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] W
Hi
We are working within a constrained environment which defines a set of
custom actions and custom tables for a deployment framework using wix.
I am looking at creating simple patches for MSIs which will ONLY copy
modified files or new files to servers as some of the MSIs are reasonably
comple
Bob -
Just want to say thanks for your help .. y'all are doing great things!
- Troy
On Sat, Jun 6, 2009 at 6:16 PM, Bob Arnson wrote:
> troy hostetter wrote:
> > So .. if I understand this correctly .. Windows Installer 4.5 supports
> > execution of custom actions on patch removal via the use
troy hostetter wrote:
> So .. if I understand this correctly .. Windows Installer 4.5 supports
> execution of custom actions on patch removal via the use of the Custom
> Action Patch Uninstall Option (msidbCustomActionTypePatchUninstall) .. and
> WiX CustomAction supports this as well via the use o
Bob -
So .. if I understand this correctly .. Windows Installer 4.5 supports
execution of custom actions on patch removal via the use of the Custom
Action Patch Uninstall Option (msidbCustomActionTypePatchUninstall) .. and
WiX CustomAction supports this as well via the use of the PatchUninstall
at
troy hostetter wrote:
> File="[KCENTERPRISE.ROOT.WEBDIR]web.config" Action="delete" On="uninstall"
> ElementPath="//configuration/appSettings" Node="element"
> VerifyPath="add[...@key='SearchDefaultConfigSection'[\]]"
> Sequence="20" />
>
> And they do not s
It isn't until MSI 4.5 that CustomActions can get enough data to work
correctly on patch uninstall. It also requires some really complicated
code. None of the WiX CustomActions support it yet. You could file a
feature request if you'd like.
troy hostetter wrote:
> I was able to successfully pat
I was able to successfully patch the msi .. had to pass in the transforms on
the command line as properties .. and found out they had to be all caps in
the WiX xml.
I am now puzzled on the uninstall of the patch. I have my xmlConfig
statements as such:
And they do not seem to be execut
troy hostetter wrote:
> error PYRO0260 : Product '{1F6FE067-01BE-4D39-B880-0AEF3E4F84D0}': Table
> 'CreateFolder' has a new row 'TARGETDIR/C__Search.AppSettings' added. This
> makes the patch not uninstallable.
> pyro.exe : error PYRO0261 : This patch is not uninstallable. The 'Patch'
> element's a
I must be missing something simple. I verified that the "diff" file
(diff.wixmst) has my new components in it. Each "row" for my new components
has a "wrote:
> This is really odd. I created a small patch demo project, and was able to
> patch an existing xml file using XmlConfig, however my main
This is really odd. I created a small patch demo project, and was able to
patch an existing xml file using XmlConfig, however my main WiX project is
not able to generate a patch :(
I attempted the KeyPath setting as shown here:
However,
Verbose log file should show you what Components are being changed. My
bet is that your 10 unchanged Components KeyPaths are not being updated.
troy hostetter wrote:
> I am attempting to patch an existing web.config file with new web.config
> settings. When I execute msiexec and pass in the msp
troy hostetter wrote:
> I am attempting to patch an existing web.config file with new web.config
> settings. When I execute msiexec and pass in the msp file, the
> "util:XmlConfig" patches are not being applied.
>
Verbose logging will show the action state of every component.
--
sig://boB
ht
I am attempting to patch an existing web.config file with new web.config
settings. When I execute msiexec and pass in the msp file, the
"util:XmlConfig" patches are not being applied.
My Tools.v1.0.1.Patch.wxs file looks like:
*
http://schemas.microsoft.com/wix/2006/wi";>
I've actually abandoned this mode of creating patches in favor of the msimsp
method. Not sure what I was doing wrong, but I know this is working, so
we'll have to come back to it later. Thanks for the reply though!
Stryder
On Fri, Apr 3, 2009 at 2:46 PM, Heath Stewart wrote:
> MSMs would alrea
MSMs would already be merged into the the MSI at that point, so any
differences in your MSMs will be visible. But it depends on your patch
authoring. What does your patch source file look like? Can you post it or a
sample online?
On Fri, Apr 3, 2009 at 11:24 AM, Stryder Crown wrote:
> Learning W
Learning WiX, getting into patching and have all sorts of confusion. But,
maybe someone can clarify for me:
When running torch on two .msi files (the original and the updated one),
torch isn't going to find differences in referenced merge modules is it?
Which means my transform file isn't going t
Hi,
We are having issues with slipstreaming our RTM product with the SP1 MSP patch. The following error is thrown when the patch is being applied.
Error 2920: Source directory not specified for file catalog.51B6FD4C_6551_1104_FF1F_C8B3B9A1E18E.
We are creating the patch using
Alan W. Waddington wrote:
I now face another issue in that the patch file does not update
anything on my target machine. The patch does not report any errors
on execution and completes successfully, but on checking the
application there is no change, neither is there a change in the
version
I have now successfully created the patch file after using the admin
install of two compressed msi's.
I now face another issue in that the patch file does not update anything
on my target machine. The patch does not report any errors on execution
and completes successfully, but on checking the
Alan W. Waddington wrote:
My issue is that I initially tried to create the patch to find out
that you can't use compressed files. I then changed the wxs file to
remove the compression.
To build a patch, you need uncompressed files. However, you can still
install using compressed files --
Hi All
I've been trying to create a patch for our product using WiX v2.0.4221.0
My issue is that I initially tried to create the patch to find out that
you can't use compressed files. I then changed the wxs file to remove
the compression. The build still creates the msi but it's smaller t
29 matches
Mail list logo
