Quantcast

Patch Creation Issues

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Patch Creation Issues

Aaron DeMarre
Hello all, I am having some issues creating a patch and was hoping to get
some insight.

I am using the "Using Purly Wix" guide here:
http://wix.sourceforge.net/manual-wix3/wix_patching.htm and have created
many successful patches with this method. In this latest patch I am adding
two files, and now I am having issues with the process. I am using Wix 3.5,
torch.exe reports 3.5.2124.0.

1) The output from torch.exe does not appear to be correct, the .msp it
outputs includes a lot of files that have not been changed in years. I did a
binary diff on some of them, and there are no differences between the new
and old files. The component IDs did not change, and these are
unversioned help files. I cannot figure out when torch thinks they are
modified.

2) The inclusion of ComponentRefs in the PatchFamily of patch.wxs does not
seem to have any control over what is included in the .msp. I noticed this
some time ago in previous patches, but was actually thankful for this since
a file that needed to be updated was not included in patch.wxs but made it
into the patch. However, now a change in the default config file we ship
with the product is causing issues, and I want to specifically exclude this
file from the patch. It seems the patch is being made against the output of
torch.exe and the ComponentRef entries in patch.exe are being ignored
entirely.

3) Unrelated to the two issues above, the patches are clearing
the ARPINSTALLLOCATION property in the registry. I have this property set in
the installer as a custom action with the condition "(NOT Installed) AND
(NOT PATCH)" in order to prevent this. I am not sure if the custom action is
running on patches with a blank value for the ARPINSTALLLOCATION property,
or if my conditions are actually causing the property to not be set when it
should be set during a patch. Or if this is an issue with the patch itself,
and not the installer it is patching.

Any help would be appreciated, especially on how to control (exclude) files
from getting into the patch.

Thanks in advance,
Aaron DeMarre
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch Creation Issues

Aaron DeMarre
I should add that I get a very different output from torch.exe when I remove
the files that are to be added in the patch. These files were added as
components to the top level feature, which is always installed. However, I
cannot see a pattern to what files are included in the .msp torch.exe
outputs, some modified files are included, others are not.

-Aaron

On Fri, Jan 14, 2011 at 11:28 AM, Aaron DeMarre <[hidden email]> wrote:

> Hello all, I am having some issues creating a patch and was hoping to get
> some insight.
>
> I am using the "Using Purly Wix" guide here:
> http://wix.sourceforge.net/manual-wix3/wix_patching.htm and have created
> many successful patches with this method. In this latest patch I am adding
> two files, and now I am having issues with the process. I am using Wix 3.5,
> torch.exe reports 3.5.2124.0.
>
> 1) The output from torch.exe does not appear to be correct, the .msp it
> outputs includes a lot of files that have not been changed in years. I did a
> binary diff on some of them, and there are no differences between the new
> and old files. The component IDs did not change, and these are
> unversioned help files. I cannot figure out when torch thinks they are
> modified.
>
> 2) The inclusion of ComponentRefs in the PatchFamily of patch.wxs does not
> seem to have any control over what is included in the .msp. I noticed this
> some time ago in previous patches, but was actually thankful for this since
> a file that needed to be updated was not included in patch.wxs but made it
> into the patch. However, now a change in the default config file we ship
> with the product is causing issues, and I want to specifically exclude this
> file from the patch. It seems the patch is being made against the output of
> torch.exe and the ComponentRef entries in patch.exe are being ignored
> entirely.
>
> 3) Unrelated to the two issues above, the patches are clearing
> the ARPINSTALLLOCATION property in the registry. I have this property set in
> the installer as a custom action with the condition "(NOT Installed) AND
> (NOT PATCH)" in order to prevent this. I am not sure if the custom action is
> running on patches with a blank value for the ARPINSTALLLOCATION property,
> or if my conditions are actually causing the property to not be set when it
> should be set during a patch. Or if this is an issue with the patch itself,
> and not the installer it is patching.
>
> Any help would be appreciated, especially on how to control (exclude) files
> from getting into the patch.
>
> Thanks in advance,
> Aaron DeMarre
>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch Creation Issues

Blair Murri-3
Some notes on how that patch creation process works:

1. Torch doesn't look at the files themselves, only at the metadata for them
already captured in Windows Installer tables. In part because of this (but
mostly because some other data that isn't likely to change is also needed
when building the MSP) the output of torch used to build patches (produced
using the "/p" switch) contains all data, not just the changed data. Pyro
does the reduction of data down to just the changed items (it's also Pyro
that does the file comparisons). Consider Torch output intended for Pyro to
be intermediate data, not an indication of final output.

2. Source code Fragment membership (from the "upgraded" sources) is
maintained through Torch into Pyro. *Refs under PatchFamily cause all
changes in the same Fragment (or other similar "fragments", such as Product)
to be included in the patch. To exclude those, you need to have the
components you do not wish to include in a fragment that is not shared by
anything referenced by the PathFamily. Note that if you do not have anything
referenced, every change is in the patch. Conversely, if you do want some
change to be included, reference something in its fragment.

3. Use a verbose log to determine why/when your property is being
cleared/not set erroneously. Compare a verbose log from a non-patched
installation and one from the patched one.

Blair

-----Original Message-----
From: Aaron DeMarre [mailto:[hidden email]]
Sent: Friday, January 14, 2011 12:23 PM
To: [hidden email]
Subject: Re: [WiX-users] Patch Creation Issues

I should add that I get a very different output from torch.exe when I remove
the files that are to be added in the patch. These files were added as
components to the top level feature, which is always installed. However, I
cannot see a pattern to what files are included in the .msp torch.exe
outputs, some modified files are included, others are not.

-Aaron

On Fri, Jan 14, 2011 at 11:28 AM, Aaron DeMarre <[hidden email]> wrote:

> Hello all, I am having some issues creating a patch and was hoping to get
> some insight.
>
> I am using the "Using Purly Wix" guide here:
> http://wix.sourceforge.net/manual-wix3/wix_patching.htm and have created
> many successful patches with this method. In this latest patch I am adding
> two files, and now I am having issues with the process. I am using Wix
3.5,
> torch.exe reports 3.5.2124.0.
>
> 1) The output from torch.exe does not appear to be correct, the .msp it
> outputs includes a lot of files that have not been changed in years. I did
a
> binary diff on some of them, and there are no differences between the new
> and old files. The component IDs did not change, and these are
> unversioned help files. I cannot figure out when torch thinks they are
> modified.
>
> 2) The inclusion of ComponentRefs in the PatchFamily of patch.wxs does not
> seem to have any control over what is included in the .msp. I noticed this
> some time ago in previous patches, but was actually thankful for this
since
> a file that needed to be updated was not included in patch.wxs but made it
> into the patch. However, now a change in the default config file we ship
> with the product is causing issues, and I want to specifically exclude
this
> file from the patch. It seems the patch is being made against the output
of
> torch.exe and the ComponentRef entries in patch.exe are being ignored
> entirely.
>
> 3) Unrelated to the two issues above, the patches are clearing
> the ARPINSTALLLOCATION property in the registry. I have this property set
in
> the installer as a custom action with the condition "(NOT Installed) AND
> (NOT PATCH)" in order to prevent this. I am not sure if the custom action
is
> running on patches with a blank value for the ARPINSTALLLOCATION property,
> or if my conditions are actually causing the property to not be set when
it
> should be set during a patch. Or if this is an issue with the patch
itself,
> and not the installer it is patching.
>
> Any help would be appreciated, especially on how to control (exclude)
files
> from getting into the patch.
>
> Thanks in advance,
> Aaron DeMarre
>
----------------------------------------------------------------------------
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch Creation Issues

Aaron DeMarre
Thank you that gives me something to go on. I have all my components in the
same fragment, so now I understand what is going on with PatchFamily. If I
were to move all changed components into a separate fragment in the updated
installer, would this have any effect? Or does it use the fragments declared
in the original installer?

-Aaron

On Sat, Jan 15, 2011 at 2:39 AM, Blair <[hidden email]> wrote:

> Some notes on how that patch creation process works:
>
> 1. Torch doesn't look at the files themselves, only at the metadata for
> them
> already captured in Windows Installer tables. In part because of this (but
> mostly because some other data that isn't likely to change is also needed
> when building the MSP) the output of torch used to build patches (produced
> using the "/p" switch) contains all data, not just the changed data. Pyro
> does the reduction of data down to just the changed items (it's also Pyro
> that does the file comparisons). Consider Torch output intended for Pyro to
> be intermediate data, not an indication of final output.
>
> 2. Source code Fragment membership (from the "upgraded" sources) is
> maintained through Torch into Pyro. *Refs under PatchFamily cause all
> changes in the same Fragment (or other similar "fragments", such as
> Product)
> to be included in the patch. To exclude those, you need to have the
> components you do not wish to include in a fragment that is not shared by
> anything referenced by the PathFamily. Note that if you do not have
> anything
> referenced, every change is in the patch. Conversely, if you do want some
> change to be included, reference something in its fragment.
>
> 3. Use a verbose log to determine why/when your property is being
> cleared/not set erroneously. Compare a verbose log from a non-patched
> installation and one from the patched one.
>
> Blair
>
> -----Original Message-----
> From: Aaron DeMarre [mailto:[hidden email]]
> Sent: Friday, January 14, 2011 12:23 PM
> To: [hidden email]
> Subject: Re: [WiX-users] Patch Creation Issues
>
> I should add that I get a very different output from torch.exe when I
> remove
> the files that are to be added in the patch. These files were added as
> components to the top level feature, which is always installed. However, I
> cannot see a pattern to what files are included in the .msp torch.exe
> outputs, some modified files are included, others are not.
>
> -Aaron
>
> On Fri, Jan 14, 2011 at 11:28 AM, Aaron DeMarre <[hidden email]>
> wrote:
>
> > Hello all, I am having some issues creating a patch and was hoping to get
> > some insight.
> >
> > I am using the "Using Purly Wix" guide here:
> > http://wix.sourceforge.net/manual-wix3/wix_patching.htm and have created
> > many successful patches with this method. In this latest patch I am
> adding
> > two files, and now I am having issues with the process. I am using Wix
> 3.5,
> > torch.exe reports 3.5.2124.0.
> >
> > 1) The output from torch.exe does not appear to be correct, the .msp it
> > outputs includes a lot of files that have not been changed in years. I
> did
> a
> > binary diff on some of them, and there are no differences between the new
> > and old files. The component IDs did not change, and these are
> > unversioned help files. I cannot figure out when torch thinks they are
> > modified.
> >
> > 2) The inclusion of ComponentRefs in the PatchFamily of patch.wxs does
> not
> > seem to have any control over what is included in the .msp. I noticed
> this
> > some time ago in previous patches, but was actually thankful for this
> since
> > a file that needed to be updated was not included in patch.wxs but made
> it
> > into the patch. However, now a change in the default config file we ship
> > with the product is causing issues, and I want to specifically exclude
> this
> > file from the patch. It seems the patch is being made against the output
> of
> > torch.exe and the ComponentRef entries in patch.exe are being ignored
> > entirely.
> >
> > 3) Unrelated to the two issues above, the patches are clearing
> > the ARPINSTALLLOCATION property in the registry. I have this property set
> in
> > the installer as a custom action with the condition "(NOT Installed) AND
> > (NOT PATCH)" in order to prevent this. I am not sure if the custom action
> is
> > running on patches with a blank value for the ARPINSTALLLOCATION
> property,
> > or if my conditions are actually causing the property to not be set when
> it
> > should be set during a patch. Or if this is an issue with the patch
> itself,
> > and not the installer it is patching.
> >
> > Any help would be appreciated, especially on how to control (exclude)
> files
> > from getting into the patch.
> >
> > Thanks in advance,
> > Aaron DeMarre
> >
>
> ----------------------------------------------------------------------------
> --
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch Creation Issues

Blair Murri-3
As I understand it, it uses the fragmentation of the updated installer (and
ignores the fragmentation of the original), but Peter is a much better
authority than I on that.

-Blair

-----Original Message-----
From: Aaron DeMarre [mailto:[hidden email]]
Sent: Monday, January 17, 2011 10:12 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patch Creation Issues

Thank you that gives me something to go on. I have all my components in the
same fragment, so now I understand what is going on with PatchFamily. If I
were to move all changed components into a separate fragment in the updated
installer, would this have any effect? Or does it use the fragments declared
in the original installer?

-Aaron

On Sat, Jan 15, 2011 at 2:39 AM, Blair <[hidden email]> wrote:

> Some notes on how that patch creation process works:
>
> 1. Torch doesn't look at the files themselves, only at the metadata for
> them
> already captured in Windows Installer tables. In part because of this (but
> mostly because some other data that isn't likely to change is also needed
> when building the MSP) the output of torch used to build patches (produced
> using the "/p" switch) contains all data, not just the changed data. Pyro
> does the reduction of data down to just the changed items (it's also Pyro
> that does the file comparisons). Consider Torch output intended for Pyro
to

> be intermediate data, not an indication of final output.
>
> 2. Source code Fragment membership (from the "upgraded" sources) is
> maintained through Torch into Pyro. *Refs under PatchFamily cause all
> changes in the same Fragment (or other similar "fragments", such as
> Product)
> to be included in the patch. To exclude those, you need to have the
> components you do not wish to include in a fragment that is not shared by
> anything referenced by the PathFamily. Note that if you do not have
> anything
> referenced, every change is in the patch. Conversely, if you do want some
> change to be included, reference something in its fragment.
>
> 3. Use a verbose log to determine why/when your property is being
> cleared/not set erroneously. Compare a verbose log from a non-patched
> installation and one from the patched one.
>
> Blair
>
> -----Original Message-----
> From: Aaron DeMarre [mailto:[hidden email]]
> Sent: Friday, January 14, 2011 12:23 PM
> To: [hidden email]
> Subject: Re: [WiX-users] Patch Creation Issues
>
> I should add that I get a very different output from torch.exe when I
> remove
> the files that are to be added in the patch. These files were added as
> components to the top level feature, which is always installed. However, I
> cannot see a pattern to what files are included in the .msp torch.exe
> outputs, some modified files are included, others are not.
>
> -Aaron
>
> On Fri, Jan 14, 2011 at 11:28 AM, Aaron DeMarre <[hidden email]>
> wrote:
>
> > Hello all, I am having some issues creating a patch and was hoping to
get

> > some insight.
> >
> > I am using the "Using Purly Wix" guide here:
> > http://wix.sourceforge.net/manual-wix3/wix_patching.htm and have created
> > many successful patches with this method. In this latest patch I am
> adding
> > two files, and now I am having issues with the process. I am using Wix
> 3.5,
> > torch.exe reports 3.5.2124.0.
> >
> > 1) The output from torch.exe does not appear to be correct, the .msp it
> > outputs includes a lot of files that have not been changed in years. I
> did
> a
> > binary diff on some of them, and there are no differences between the
new

> > and old files. The component IDs did not change, and these are
> > unversioned help files. I cannot figure out when torch thinks they are
> > modified.
> >
> > 2) The inclusion of ComponentRefs in the PatchFamily of patch.wxs does
> not
> > seem to have any control over what is included in the .msp. I noticed
> this
> > some time ago in previous patches, but was actually thankful for this
> since
> > a file that needed to be updated was not included in patch.wxs but made
> it
> > into the patch. However, now a change in the default config file we ship
> > with the product is causing issues, and I want to specifically exclude
> this
> > file from the patch. It seems the patch is being made against the output
> of
> > torch.exe and the ComponentRef entries in patch.exe are being ignored
> > entirely.
> >
> > 3) Unrelated to the two issues above, the patches are clearing
> > the ARPINSTALLLOCATION property in the registry. I have this property
set
> in
> > the installer as a custom action with the condition "(NOT Installed) AND
> > (NOT PATCH)" in order to prevent this. I am not sure if the custom
action

> is
> > running on patches with a blank value for the ARPINSTALLLOCATION
> property,
> > or if my conditions are actually causing the property to not be set when
> it
> > should be set during a patch. Or if this is an issue with the patch
> itself,
> > and not the installer it is patching.
> >
> > Any help would be appreciated, especially on how to control (exclude)
> files
> > from getting into the patch.
> >
> > Thanks in advance,
> > Aaron DeMarre
> >
>
>
----------------------------------------------------------------------------

> --
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
----------------------------------------------------------------------------
--

> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
----------------------------------------------------------------------------
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users


------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch Creation Issues

Aaron DeMarre
Thanks for the info. I played around with this a bit, but still could not
get a patch I was happy with. I switched to the patchwiz.dll process and it
is giving me the behavior I expect when adding new files to the patch.

-Aaron

On Tue, Jan 18, 2011 at 8:54 PM, Blair <[hidden email]> wrote:

> As I understand it, it uses the fragmentation of the updated installer (and
> ignores the fragmentation of the original), but Peter is a much better
> authority than I on that.
>
> -Blair
>
> -----Original Message-----
> From: Aaron DeMarre [mailto:[hidden email]]
> Sent: Monday, January 17, 2011 10:12 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Patch Creation Issues
>
> Thank you that gives me something to go on. I have all my components in the
> same fragment, so now I understand what is going on with PatchFamily. If I
> were to move all changed components into a separate fragment in the updated
> installer, would this have any effect? Or does it use the fragments
> declared
> in the original installer?
>
> -Aaron
>
> On Sat, Jan 15, 2011 at 2:39 AM, Blair <[hidden email]> wrote:
>
> > Some notes on how that patch creation process works:
> >
> > 1. Torch doesn't look at the files themselves, only at the metadata for
> > them
> > already captured in Windows Installer tables. In part because of this
> (but
> > mostly because some other data that isn't likely to change is also needed
> > when building the MSP) the output of torch used to build patches
> (produced
> > using the "/p" switch) contains all data, not just the changed data. Pyro
> > does the reduction of data down to just the changed items (it's also Pyro
> > that does the file comparisons). Consider Torch output intended for Pyro
> to
> > be intermediate data, not an indication of final output.
> >
> > 2. Source code Fragment membership (from the "upgraded" sources) is
> > maintained through Torch into Pyro. *Refs under PatchFamily cause all
> > changes in the same Fragment (or other similar "fragments", such as
> > Product)
> > to be included in the patch. To exclude those, you need to have the
> > components you do not wish to include in a fragment that is not shared by
> > anything referenced by the PathFamily. Note that if you do not have
> > anything
> > referenced, every change is in the patch. Conversely, if you do want some
> > change to be included, reference something in its fragment.
> >
> > 3. Use a verbose log to determine why/when your property is being
> > cleared/not set erroneously. Compare a verbose log from a non-patched
> > installation and one from the patched one.
> >
> > Blair
> >
> > -----Original Message-----
> > From: Aaron DeMarre [mailto:[hidden email]]
> > Sent: Friday, January 14, 2011 12:23 PM
> > To: [hidden email]
> > Subject: Re: [WiX-users] Patch Creation Issues
> >
> > I should add that I get a very different output from torch.exe when I
> > remove
> > the files that are to be added in the patch. These files were added as
> > components to the top level feature, which is always installed. However,
> I
> > cannot see a pattern to what files are included in the .msp torch.exe
> > outputs, some modified files are included, others are not.
> >
> > -Aaron
> >
> > On Fri, Jan 14, 2011 at 11:28 AM, Aaron DeMarre <[hidden email]>
> > wrote:
> >
> > > Hello all, I am having some issues creating a patch and was hoping to
> get
> > > some insight.
> > >
> > > I am using the "Using Purly Wix" guide here:
> > > http://wix.sourceforge.net/manual-wix3/wix_patching.htm and have
> created
> > > many successful patches with this method. In this latest patch I am
> > adding
> > > two files, and now I am having issues with the process. I am using Wix
> > 3.5,
> > > torch.exe reports 3.5.2124.0.
> > >
> > > 1) The output from torch.exe does not appear to be correct, the .msp it
> > > outputs includes a lot of files that have not been changed in years. I
> > did
> > a
> > > binary diff on some of them, and there are no differences between the
> new
> > > and old files. The component IDs did not change, and these are
> > > unversioned help files. I cannot figure out when torch thinks they are
> > > modified.
> > >
> > > 2) The inclusion of ComponentRefs in the PatchFamily of patch.wxs does
> > not
> > > seem to have any control over what is included in the .msp. I noticed
> > this
> > > some time ago in previous patches, but was actually thankful for this
> > since
> > > a file that needed to be updated was not included in patch.wxs but made
> > it
> > > into the patch. However, now a change in the default config file we
> ship
> > > with the product is causing issues, and I want to specifically exclude
> > this
> > > file from the patch. It seems the patch is being made against the
> output
> > of
> > > torch.exe and the ComponentRef entries in patch.exe are being ignored
> > > entirely.
> > >
> > > 3) Unrelated to the two issues above, the patches are clearing
> > > the ARPINSTALLLOCATION property in the registry. I have this property
> set
> > in
> > > the installer as a custom action with the condition "(NOT Installed)
> AND
> > > (NOT PATCH)" in order to prevent this. I am not sure if the custom
> action
> > is
> > > running on patches with a blank value for the ARPINSTALLLOCATION
> > property,
> > > or if my conditions are actually causing the property to not be set
> when
> > it
> > > should be set during a patch. Or if this is an issue with the patch
> > itself,
> > > and not the installer it is patching.
> > >
> > > Any help would be appreciated, especially on how to control (exclude)
> > files
> > > from getting into the patch.
> > >
> > > Thanks in advance,
> > > Aaron DeMarre
> > >
> >
> >
>
> ----------------------------------------------------------------------------
> > --
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them. Understand
> > malware threats, the impact they can have on your business, and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
>
> ----------------------------------------------------------------------------
> --
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them. Understand
> > malware threats, the impact they can have on your business, and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> ----------------------------------------------------------------------------
> --
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch Creation Issues

Blair Murri-3
I'm not sure how you exclude your default config file changes with PatchWiz,
but then again I gave up on PatchWiz after it hung my build system one too
many times.

-Blair

-----Original Message-----
From: Aaron DeMarre [mailto:[hidden email]]
Sent: Thursday, January 20, 2011 12:36 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patch Creation Issues

Thanks for the info. I played around with this a bit, but still could not
get a patch I was happy with. I switched to the patchwiz.dll process and it
is giving me the behavior I expect when adding new files to the patch.

-Aaron

On Tue, Jan 18, 2011 at 8:54 PM, Blair <[hidden email]> wrote:

> As I understand it, it uses the fragmentation of the updated installer
(and

> ignores the fragmentation of the original), but Peter is a much better
> authority than I on that.
>
> -Blair
>
> -----Original Message-----
> From: Aaron DeMarre [mailto:[hidden email]]
> Sent: Monday, January 17, 2011 10:12 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Patch Creation Issues
>
> Thank you that gives me something to go on. I have all my components in
the
> same fragment, so now I understand what is going on with PatchFamily. If I
> were to move all changed components into a separate fragment in the
updated

> installer, would this have any effect? Or does it use the fragments
> declared
> in the original installer?
>
> -Aaron
>
> On Sat, Jan 15, 2011 at 2:39 AM, Blair <[hidden email]> wrote:
>
> > Some notes on how that patch creation process works:
> >
> > 1. Torch doesn't look at the files themselves, only at the metadata for
> > them
> > already captured in Windows Installer tables. In part because of this
> (but
> > mostly because some other data that isn't likely to change is also
needed
> > when building the MSP) the output of torch used to build patches
> (produced
> > using the "/p" switch) contains all data, not just the changed data.
Pyro
> > does the reduction of data down to just the changed items (it's also
Pyro

> > that does the file comparisons). Consider Torch output intended for Pyro
> to
> > be intermediate data, not an indication of final output.
> >
> > 2. Source code Fragment membership (from the "upgraded" sources) is
> > maintained through Torch into Pyro. *Refs under PatchFamily cause all
> > changes in the same Fragment (or other similar "fragments", such as
> > Product)
> > to be included in the patch. To exclude those, you need to have the
> > components you do not wish to include in a fragment that is not shared
by
> > anything referenced by the PathFamily. Note that if you do not have
> > anything
> > referenced, every change is in the patch. Conversely, if you do want
some

> > change to be included, reference something in its fragment.
> >
> > 3. Use a verbose log to determine why/when your property is being
> > cleared/not set erroneously. Compare a verbose log from a non-patched
> > installation and one from the patched one.
> >
> > Blair
> >
> > -----Original Message-----
> > From: Aaron DeMarre [mailto:[hidden email]]
> > Sent: Friday, January 14, 2011 12:23 PM
> > To: [hidden email]
> > Subject: Re: [WiX-users] Patch Creation Issues
> >
> > I should add that I get a very different output from torch.exe when I
> > remove
> > the files that are to be added in the patch. These files were added as
> > components to the top level feature, which is always installed. However,
> I
> > cannot see a pattern to what files are included in the .msp torch.exe
> > outputs, some modified files are included, others are not.
> >
> > -Aaron
> >
> > On Fri, Jan 14, 2011 at 11:28 AM, Aaron DeMarre <[hidden email]>
> > wrote:
> >
> > > Hello all, I am having some issues creating a patch and was hoping to
> get
> > > some insight.
> > >
> > > I am using the "Using Purly Wix" guide here:
> > > http://wix.sourceforge.net/manual-wix3/wix_patching.htm and have
> created
> > > many successful patches with this method. In this latest patch I am
> > adding
> > > two files, and now I am having issues with the process. I am using Wix
> > 3.5,
> > > torch.exe reports 3.5.2124.0.
> > >
> > > 1) The output from torch.exe does not appear to be correct, the .msp
it

> > > outputs includes a lot of files that have not been changed in years. I
> > did
> > a
> > > binary diff on some of them, and there are no differences between the
> new
> > > and old files. The component IDs did not change, and these are
> > > unversioned help files. I cannot figure out when torch thinks they are
> > > modified.
> > >
> > > 2) The inclusion of ComponentRefs in the PatchFamily of patch.wxs does
> > not
> > > seem to have any control over what is included in the .msp. I noticed
> > this
> > > some time ago in previous patches, but was actually thankful for this
> > since
> > > a file that needed to be updated was not included in patch.wxs but
made

> > it
> > > into the patch. However, now a change in the default config file we
> ship
> > > with the product is causing issues, and I want to specifically exclude
> > this
> > > file from the patch. It seems the patch is being made against the
> output
> > of
> > > torch.exe and the ComponentRef entries in patch.exe are being ignored
> > > entirely.
> > >
> > > 3) Unrelated to the two issues above, the patches are clearing
> > > the ARPINSTALLLOCATION property in the registry. I have this property
> set
> > in
> > > the installer as a custom action with the condition "(NOT Installed)
> AND
> > > (NOT PATCH)" in order to prevent this. I am not sure if the custom
> action
> > is
> > > running on patches with a blank value for the ARPINSTALLLOCATION
> > property,
> > > or if my conditions are actually causing the property to not be set
> when
> > it
> > > should be set during a patch. Or if this is an issue with the patch
> > itself,
> > > and not the installer it is patching.
> > >
> > > Any help would be appreciated, especially on how to control (exclude)
> > files
> > > from getting into the patch.
> > >
> > > Thanks in advance,
> > > Aaron DeMarre
> > >
> >
> >
>
>
----------------------------------------------------------------------------

> > --
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them. Understand
> > malware threats, the impact they can have on your business, and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
>
>
----------------------------------------------------------------------------

> --
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them. Understand
> > malware threats, the impact they can have on your business, and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
>
----------------------------------------------------------------------------

> --
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
----------------------------------------------------------------------------
--

> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
----------------------------------------------------------------------------
--
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand
malware threats, the impact they can have on your business, and how you
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users


------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch Creation Issues

Aaron DeMarre
Blair, first off, thanks for your help! I really appreciate it.

After more investigation (i.e. I rechecked the svn commit dates) my default
config file was not changed between the original installer creation and the
patch creation, which makes it even more perplexing to me. And to add to my
confusion, it was not installing the default config file during patching,
but rather restoring the default config file upon uninstallation of the
patch.

My understanding of what happens during the uninstallation of a patch is
limited, but this file is marked permanent, so even if the product was fully
reinstalled, I assumed it would fall under the "Nonversioned Files are User
Data" rule of the file versioning. I have never had this issue in the past,
so I cannot figure out why this is happening only when new files are added
to the patch, and not happening when existing files are updated. This
behavior, along with the big change in output from torch.exe when new files
are added to the patch raises red flags in this process for me.

I think you are right about patchwiz, I do not see a way to exclude files in
this process. I could see this causing a lot of issues in the future if I
want to release a new installer and a patch that can be applied to both.

And finally, from my testing it seems ARPINSTALLLOCATION must be set every
time a patch is applied, so the correct condition for the custom action that
sets this is "NOT REMOVE". Since there is no going back now, it looks like
it is a bug in our installer that we are going to have to live with, unless
there is a way to redefine the conditions of a custom action in a patch that
I am not aware of.

Thanks again,
-Aaron

On Thu, Jan 20, 2011 at 8:42 PM, Blair <[hidden email]> wrote:

> I'm not sure how you exclude your default config file changes with
> PatchWiz,
> but then again I gave up on PatchWiz after it hung my build system one too
> many times.
>
> -Blair
>
> -----Original Message-----
> From: Aaron DeMarre [mailto:[hidden email]]
> Sent: Thursday, January 20, 2011 12:36 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Patch Creation Issues
>
> Thanks for the info. I played around with this a bit, but still could not
> get a patch I was happy with. I switched to the patchwiz.dll process and it
> is giving me the behavior I expect when adding new files to the patch.
>
> -Aaron
>
> On Tue, Jan 18, 2011 at 8:54 PM, Blair <[hidden email]> wrote:
>
> > As I understand it, it uses the fragmentation of the updated installer
> (and
> > ignores the fragmentation of the original), but Peter is a much better
> > authority than I on that.
> >
> > -Blair
> >
> > -----Original Message-----
> > From: Aaron DeMarre [mailto:[hidden email]]
> > Sent: Monday, January 17, 2011 10:12 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Patch Creation Issues
> >
> > Thank you that gives me something to go on. I have all my components in
> the
> > same fragment, so now I understand what is going on with PatchFamily. If
> I
> > were to move all changed components into a separate fragment in the
> updated
> > installer, would this have any effect? Or does it use the fragments
> > declared
> > in the original installer?
> >
> > -Aaron
> >
> > On Sat, Jan 15, 2011 at 2:39 AM, Blair <[hidden email]> wrote:
> >
> > > Some notes on how that patch creation process works:
> > >
> > > 1. Torch doesn't look at the files themselves, only at the metadata for
> > > them
> > > already captured in Windows Installer tables. In part because of this
> > (but
> > > mostly because some other data that isn't likely to change is also
> needed
> > > when building the MSP) the output of torch used to build patches
> > (produced
> > > using the "/p" switch) contains all data, not just the changed data.
> Pyro
> > > does the reduction of data down to just the changed items (it's also
> Pyro
> > > that does the file comparisons). Consider Torch output intended for
> Pyro
> > to
> > > be intermediate data, not an indication of final output.
> > >
> > > 2. Source code Fragment membership (from the "upgraded" sources) is
> > > maintained through Torch into Pyro. *Refs under PatchFamily cause all
> > > changes in the same Fragment (or other similar "fragments", such as
> > > Product)
> > > to be included in the patch. To exclude those, you need to have the
> > > components you do not wish to include in a fragment that is not shared
> by
> > > anything referenced by the PathFamily. Note that if you do not have
> > > anything
> > > referenced, every change is in the patch. Conversely, if you do want
> some
> > > change to be included, reference something in its fragment.
> > >
> > > 3. Use a verbose log to determine why/when your property is being
> > > cleared/not set erroneously. Compare a verbose log from a non-patched
> > > installation and one from the patched one.
> > >
> > > Blair
> > >
> > > -----Original Message-----
> > > From: Aaron DeMarre [mailto:[hidden email]]
> > > Sent: Friday, January 14, 2011 12:23 PM
> > > To: [hidden email]
> > > Subject: Re: [WiX-users] Patch Creation Issues
> > >
> > > I should add that I get a very different output from torch.exe when I
> > > remove
> > > the files that are to be added in the patch. These files were added as
> > > components to the top level feature, which is always installed.
> However,
> > I
> > > cannot see a pattern to what files are included in the .msp torch.exe
> > > outputs, some modified files are included, others are not.
> > >
> > > -Aaron
> > >
> > > On Fri, Jan 14, 2011 at 11:28 AM, Aaron DeMarre <[hidden email]>
> > > wrote:
> > >
> > > > Hello all, I am having some issues creating a patch and was hoping to
> > get
> > > > some insight.
> > > >
> > > > I am using the "Using Purly Wix" guide here:
> > > > http://wix.sourceforge.net/manual-wix3/wix_patching.htm and have
> > created
> > > > many successful patches with this method. In this latest patch I am
> > > adding
> > > > two files, and now I am having issues with the process. I am using
> Wix
> > > 3.5,
> > > > torch.exe reports 3.5.2124.0.
> > > >
> > > > 1) The output from torch.exe does not appear to be correct, the .msp
> it
> > > > outputs includes a lot of files that have not been changed in years.
> I
> > > did
> > > a
> > > > binary diff on some of them, and there are no differences between the
> > new
> > > > and old files. The component IDs did not change, and these are
> > > > unversioned help files. I cannot figure out when torch thinks they
> are
> > > > modified.
> > > >
> > > > 2) The inclusion of ComponentRefs in the PatchFamily of patch.wxs
> does
> > > not
> > > > seem to have any control over what is included in the .msp. I noticed
> > > this
> > > > some time ago in previous patches, but was actually thankful for this
> > > since
> > > > a file that needed to be updated was not included in patch.wxs but
> made
> > > it
> > > > into the patch. However, now a change in the default config file we
> > ship
> > > > with the product is causing issues, and I want to specifically
> exclude
> > > this
> > > > file from the patch. It seems the patch is being made against the
> > output
> > > of
> > > > torch.exe and the ComponentRef entries in patch.exe are being ignored
> > > > entirely.
> > > >
> > > > 3) Unrelated to the two issues above, the patches are clearing
> > > > the ARPINSTALLLOCATION property in the registry. I have this property
> > set
> > > in
> > > > the installer as a custom action with the condition "(NOT Installed)
> > AND
> > > > (NOT PATCH)" in order to prevent this. I am not sure if the custom
> > action
> > > is
> > > > running on patches with a blank value for the ARPINSTALLLOCATION
> > > property,
> > > > or if my conditions are actually causing the property to not be set
> > when
> > > it
> > > > should be set during a patch. Or if this is an issue with the patch
> > > itself,
> > > > and not the installer it is patching.
> > > >
> > > > Any help would be appreciated, especially on how to control (exclude)
> > > files
> > > > from getting into the patch.
> > > >
> > > > Thanks in advance,
> > > > Aaron DeMarre
> > > >
> > >
> > >
> >
> >
>
> ----------------------------------------------------------------------------
> > > --
> > > Protect Your Site and Customers from Malware Attacks
> > > Learn about various malware tactics and how to avoid them. Understand
> > > malware threats, the impact they can have on your business, and how you
> > > can protect your company and customers by using code signing.
> > > http://p.sf.net/sfu/oracle-sfdevnl
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > >
> > >
> >
> >
>
> ----------------------------------------------------------------------------
> > --
> > > Protect Your Site and Customers from Malware Attacks
> > > Learn about various malware tactics and how to avoid them. Understand
> > > malware threats, the impact they can have on your business, and how you
> > > can protect your company and customers by using code signing.
> > > http://p.sf.net/sfu/oracle-sfdevnl
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> >
> >
>
> ----------------------------------------------------------------------------
> > --
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them. Understand
> > malware threats, the impact they can have on your business, and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
>
> ----------------------------------------------------------------------------
> --
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them. Understand
> > malware threats, the impact they can have on your business, and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> ----------------------------------------------------------------------------
> --
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch Creation Issues

Peter Marcu
Hi Aaron,

I posted this blog a while back about patching using admin images. http://blogs.msdn.com/b/pmarcu/archive/2008/05/30/patching-something-you-didnt-build-with-wix-using-wix-.aspx . I titled it to appeal to people trying to patch things they didn't build with WiX but it is just as applicable to people who built their original product with all the components in one fragment. If you go through the admin image patching process, it will create fragments for each component for you and you will be able to filter the contents of your patch as you desire using patch families.

You can also get PatchWiz equivalent behavior as far as filtering without using the legacy patchwiz process by simply not including any patch families in your patch. It will pick up all the differences.

You can redefine the conditions of a customaction in a patch. All you have to do is reference something in the same fragment as where your condition is defined. Caveat here is that the condition change wont be applicable during the uninstall of this particular patch.

-Peter

My team is hiring. Ask me about the open positions.


-----Original Message-----
From: Aaron DeMarre [mailto:[hidden email]]
Sent: Tuesday, January 25, 2011 1:23 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Patch Creation Issues

Blair, first off, thanks for your help! I really appreciate it.

After more investigation (i.e. I rechecked the svn commit dates) my default config file was not changed between the original installer creation and the patch creation, which makes it even more perplexing to me. And to add to my confusion, it was not installing the default config file during patching, but rather restoring the default config file upon uninstallation of the patch.

My understanding of what happens during the uninstallation of a patch is limited, but this file is marked permanent, so even if the product was fully reinstalled, I assumed it would fall under the "Nonversioned Files are User Data" rule of the file versioning. I have never had this issue in the past, so I cannot figure out why this is happening only when new files are added to the patch, and not happening when existing files are updated. This behavior, along with the big change in output from torch.exe when new files are added to the patch raises red flags in this process for me.

I think you are right about patchwiz, I do not see a way to exclude files in this process. I could see this causing a lot of issues in the future if I want to release a new installer and a patch that can be applied to both.

And finally, from my testing it seems ARPINSTALLLOCATION must be set every time a patch is applied, so the correct condition for the custom action that sets this is "NOT REMOVE". Since there is no going back now, it looks like it is a bug in our installer that we are going to have to live with, unless there is a way to redefine the conditions of a custom action in a patch that I am not aware of.

Thanks again,
-Aaron

On Thu, Jan 20, 2011 at 8:42 PM, Blair <[hidden email]> wrote:

> I'm not sure how you exclude your default config file changes with
> PatchWiz, but then again I gave up on PatchWiz after it hung my build
> system one too many times.
>
> -Blair
>
> -----Original Message-----
> From: Aaron DeMarre [mailto:[hidden email]]
> Sent: Thursday, January 20, 2011 12:36 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Patch Creation Issues
>
> Thanks for the info. I played around with this a bit, but still could
> not get a patch I was happy with. I switched to the patchwiz.dll
> process and it is giving me the behavior I expect when adding new files to the patch.
>
> -Aaron
>
> On Tue, Jan 18, 2011 at 8:54 PM, Blair <[hidden email]> wrote:
>
> > As I understand it, it uses the fragmentation of the updated
> > installer
> (and
> > ignores the fragmentation of the original), but Peter is a much
> > better authority than I on that.
> >
> > -Blair
> >
> > -----Original Message-----
> > From: Aaron DeMarre [mailto:[hidden email]]
> > Sent: Monday, January 17, 2011 10:12 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: Re: [WiX-users] Patch Creation Issues
> >
> > Thank you that gives me something to go on. I have all my components
> > in
> the
> > same fragment, so now I understand what is going on with
> > PatchFamily. If
> I
> > were to move all changed components into a separate fragment in the
> updated
> > installer, would this have any effect? Or does it use the fragments
> > declared in the original installer?
> >
> > -Aaron
> >
> > On Sat, Jan 15, 2011 at 2:39 AM, Blair <[hidden email]> wrote:
> >
> > > Some notes on how that patch creation process works:
> > >
> > > 1. Torch doesn't look at the files themselves, only at the
> > > metadata for them already captured in Windows Installer tables. In
> > > part because of this
> > (but
> > > mostly because some other data that isn't likely to change is also
> needed
> > > when building the MSP) the output of torch used to build patches
> > (produced
> > > using the "/p" switch) contains all data, not just the changed data.
> Pyro
> > > does the reduction of data down to just the changed items (it's
> > > also
> Pyro
> > > that does the file comparisons). Consider Torch output intended
> > > for
> Pyro
> > to
> > > be intermediate data, not an indication of final output.
> > >
> > > 2. Source code Fragment membership (from the "upgraded" sources)
> > > is maintained through Torch into Pyro. *Refs under PatchFamily
> > > cause all changes in the same Fragment (or other similar
> > > "fragments", such as
> > > Product)
> > > to be included in the patch. To exclude those, you need to have
> > > the components you do not wish to include in a fragment that is
> > > not shared
> by
> > > anything referenced by the PathFamily. Note that if you do not
> > > have anything referenced, every change is in the patch.
> > > Conversely, if you do want
> some
> > > change to be included, reference something in its fragment.
> > >
> > > 3. Use a verbose log to determine why/when your property is being
> > > cleared/not set erroneously. Compare a verbose log from a
> > > non-patched installation and one from the patched one.
> > >
> > > Blair
> > >
> > > -----Original Message-----
> > > From: Aaron DeMarre [mailto:[hidden email]]
> > > Sent: Friday, January 14, 2011 12:23 PM
> > > To: [hidden email]
> > > Subject: Re: [WiX-users] Patch Creation Issues
> > >
> > > I should add that I get a very different output from torch.exe
> > > when I remove the files that are to be added in the patch. These
> > > files were added as components to the top level feature, which is
> > > always installed.
> However,
> > I
> > > cannot see a pattern to what files are included in the .msp
> > > torch.exe outputs, some modified files are included, others are not.
> > >
> > > -Aaron
> > >
> > > On Fri, Jan 14, 2011 at 11:28 AM, Aaron DeMarre
> > > <[hidden email]>
> > > wrote:
> > >
> > > > Hello all, I am having some issues creating a patch and was
> > > > hoping to
> > get
> > > > some insight.
> > > >
> > > > I am using the "Using Purly Wix" guide here:
> > > > http://wix.sourceforge.net/manual-wix3/wix_patching.htm and have
> > created
> > > > many successful patches with this method. In this latest patch I
> > > > am
> > > adding
> > > > two files, and now I am having issues with the process. I am
> > > > using
> Wix
> > > 3.5,
> > > > torch.exe reports 3.5.2124.0.
> > > >
> > > > 1) The output from torch.exe does not appear to be correct, the
> > > > .msp
> it
> > > > outputs includes a lot of files that have not been changed in years.
> I
> > > did
> > > a
> > > > binary diff on some of them, and there are no differences
> > > > between the
> > new
> > > > and old files. The component IDs did not change, and these are
> > > > unversioned help files. I cannot figure out when torch thinks
> > > > they
> are
> > > > modified.
> > > >
> > > > 2) The inclusion of ComponentRefs in the PatchFamily of
> > > > patch.wxs
> does
> > > not
> > > > seem to have any control over what is included in the .msp. I
> > > > noticed
> > > this
> > > > some time ago in previous patches, but was actually thankful for
> > > > this
> > > since
> > > > a file that needed to be updated was not included in patch.wxs
> > > > but
> made
> > > it
> > > > into the patch. However, now a change in the default config file
> > > > we
> > ship
> > > > with the product is causing issues, and I want to specifically
> exclude
> > > this
> > > > file from the patch. It seems the patch is being made against
> > > > the
> > output
> > > of
> > > > torch.exe and the ComponentRef entries in patch.exe are being
> > > > ignored entirely.
> > > >
> > > > 3) Unrelated to the two issues above, the patches are clearing
> > > > the ARPINSTALLLOCATION property in the registry. I have this
> > > > property
> > set
> > > in
> > > > the installer as a custom action with the condition "(NOT
> > > > Installed)
> > AND
> > > > (NOT PATCH)" in order to prevent this. I am not sure if the
> > > > custom
> > action
> > > is
> > > > running on patches with a blank value for the ARPINSTALLLOCATION
> > > property,
> > > > or if my conditions are actually causing the property to not be
> > > > set
> > when
> > > it
> > > > should be set during a patch. Or if this is an issue with the
> > > > patch
> > > itself,
> > > > and not the installer it is patching.
> > > >
> > > > Any help would be appreciated, especially on how to control
> > > > (exclude)
> > > files
> > > > from getting into the patch.
> > > >
> > > > Thanks in advance,
> > > > Aaron DeMarre
> > > >
> > >
> > >
> >
> >
>
> ----------------------------------------------------------------------
> ------
> > > --
> > > Protect Your Site and Customers from Malware Attacks Learn about
> > > various malware tactics and how to avoid them. Understand malware
> > > threats, the impact they can have on your business, and how you
> > > can protect your company and customers by using code signing.
> > > http://p.sf.net/sfu/oracle-sfdevnl
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> > >
> > >
> > >
> >
> >
>
> ----------------------------------------------------------------------
> ------
> > --
> > > Protect Your Site and Customers from Malware Attacks Learn about
> > > various malware tactics and how to avoid them. Understand malware
> > > threats, the impact they can have on your business, and how you
> > > can protect your company and customers by using code signing.
> > > http://p.sf.net/sfu/oracle-sfdevnl
> > > _______________________________________________
> > > WiX-users mailing list
> > > [hidden email]
> > > https://lists.sourceforge.net/lists/listinfo/wix-users
> > >
> >
> >
>
> ----------------------------------------------------------------------
> ------
> > --
> > Protect Your Site and Customers from Malware Attacks Learn about
> > various malware tactics and how to avoid them. Understand malware
> > threats, the impact they can have on your business, and how you can
> > protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
>
> ----------------------------------------------------------------------
> ------
> --
> > Protect Your Site and Customers from Malware Attacks Learn about
> > various malware tactics and how to avoid them. Understand malware
> > threats, the impact they can have on your business, and how you can
> > protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________
> > WiX-users mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
>
> ----------------------------------------------------------------------
> ------
> --
> Protect Your Site and Customers from Malware Attacks Learn about
> various malware tactics and how to avoid them. Understand malware
> threats, the impact they can have on your business, and how you can
> protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> ----------------------------------------------------------------------
> -------- Special Offer-- Download ArcSight Logger for FREE (a $49 USD
> value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> WiX-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users


------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch Creation Issues

anilk
This post has NOT been accepted by the mailing list yet.
In reply to this post by Aaron DeMarre
Hi All,

I am able to create the update patch for the current installer because I have the .wixpdb file of the current installer for the old installers  and all I don't have the .wixpdb, I just have the .msi package in this case, how do I resolve the issue.

Thanks for the help in advance,
Anil.k
Loading...