Re: [WiX-users] Upgrade Installs and Component Rules
I assume you mean C1 and C1-prime in step 2.
I have to refresh my memory on what is allowed in a Major Upgrade vs. other
upgrades. I think that moving R3 to C1-prime must only be allowed because
this is a major upgrade. Otherwise it breaks the rules? I suspect I will
always be doing major upgrades anyway.
Thanks,
Scott
On Wed, Sep 23, 2009 at 12:10 PM, Blair os...@live.com wrote:
For V2:
1: Change ProductCode(s) (make this a major upgrade)
2: Make certain that C1 and C2 share the same condition and directory.
In
the future, if you ever need them to have different conditions/directories,
you will be forced to rename R1 (placing the renamed R1 in some new
not-yet-created component and retire/remove C1 from your authoring
entirely).
Component Id='C1' ...
File Id='R1' Keypath='yes' .../
/Component
Component Id='C1-prime' ...
!-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
!-- if R2 is a registry key --RemoveRegistryKey
Action='removeOnInstall'
.../
!-- you are out of luck if it us just a registry value --
... Id='R3'/
/Component
Blair
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Wednesday, September 23, 2009 6:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade Installs and Component Rules
And if R1 does not have a version resource? Most of the files involved will
not have version resources. They will be text/XML, arbitrary binary data,
or .jar files.
Scott
On Mon, Sep 21, 2009 at 2:19 PM, Blair os...@live.com wrote:
If you're reasonably certain that you will never need R2 again:
I assume V1 looks like this:
Component Id='C1' ...
File Id='R1' Keypath='yes' .../
... Id='R2'/
... Id='R3'/
/Component
For V2:
Preferred
1: Change ProductCode(s) (make this a major upgrade)
2: Force an updated version resource in R1 (sorry)
Component Id='C1' ...
File Id='R1' Keypath='yes' .../
!-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
!-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
!-- if R2 is a registry key --RemoveRegistryKey
Action='removeOnInstall'
.../
!-- you are out of luck if it us just a registry value --
... Id='R3'/
/Component
I can work on the extra credit latter...
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Monday, September 21, 2009 7:46 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Upgrade Installs and Component Rules
In version 1 of my application I have a component C1 which contains
multiple
resources.
C1 = { R1, R2, R3 }
The file R1 is the key path for C1.
The rest of the application requires that the resources are installed
with
the same path and names in V1 and V2.
In version 2 of my application I need to install a newer version of R3.
What's the right thing to do?
Version 2 of my application no longer needs R2.
What is the right thing to do?
(Extra credit: How does this change if R2 was the key path for the
component?)
The problems I'm having are that I can't change the name or path to the
resources because the application requires them to be found at a
particular
path - that's a pretty basic requirement that I don't think is
unreasonable.
That seems to mean that I can never split the resources into different
components and I can never remove a resource, because...
The component rules at
http://msdn.microsoft.com/en-us/library/aa367849(VS.85).aspx state:
Introduce a new component and assign it a unique component code when
making
any of the following changes:
- Any change that has not been shown by testing to be compatible with
previous versions of the component. In this case, you must also change
the
name or target location of every resource in the component.
- A change in the name or target location of any file, registry key,
shortcut, or other resource in the component. In this case, you must
also
change the name or target location of every resource in the component.
- The addition or removal of any file, registry key, shortcut, or other
resource from the component. *In this case, you must also change the
name
or target location of every resource in the component.*
That last item to me says - you can't change components ever without
breaking your application. In what universe is it possible or practical
to
change the name or target location of every resource in the component
without breaking the application?
It seems that the only way to make an installer that can be upgraded is
to
limit things to one resource per component. Is that right?
The component rules also state:
A new version of a component is assigned the same component code as
another
existing component. Modifying a component without changing the component
Re: [WiX-users] Upgrade Installs and Component Rules
It is a rule breakage no matter what, but those of us who have been in your
spot before have learned the side effects of several different rule
breakages, both short and long term.
When breaking component rules, major upgrades tend to be something you will
be forced to do sooner or later, and so it is best to design for that
eventuality. In addition, several kinds of rule breakages are simply not
possible unless the upgrade is major.
Thus, the rule-of-thumb is to always use major upgrades to fix poorly-formed
or otherwise in-need-of-reform components.
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Friday, September 25, 2009 6:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade Installs and Component Rules
I assume you mean C1 and C1-prime in step 2.
I have to refresh my memory on what is allowed in a Major Upgrade vs. other
upgrades. I think that moving R3 to C1-prime must only be allowed because
this is a major upgrade. Otherwise it breaks the rules? I suspect I will
always be doing major upgrades anyway.
Thanks,
Scott
On Wed, Sep 23, 2009 at 12:10 PM, Blair os...@live.com wrote:
For V2:
1: Change ProductCode(s) (make this a major upgrade)
2: Make certain that C1 and C2 share the same condition and directory.
In
the future, if you ever need them to have different
conditions/directories,
you will be forced to rename R1 (placing the renamed R1 in some new
not-yet-created component and retire/remove C1 from your authoring
entirely).
Component Id='C1' ...
File Id='R1' Keypath='yes' .../
/Component
Component Id='C1-prime' ...
!-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
!-- if R2 is a registry key --RemoveRegistryKey
Action='removeOnInstall'
.../
!-- you are out of luck if it us just a registry value --
... Id='R3'/
/Component
Blair
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Wednesday, September 23, 2009 6:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade Installs and Component Rules
And if R1 does not have a version resource? Most of the files involved
will
not have version resources. They will be text/XML, arbitrary binary data,
or .jar files.
Scott
On Mon, Sep 21, 2009 at 2:19 PM, Blair os...@live.com wrote:
If you're reasonably certain that you will never need R2 again:
I assume V1 looks like this:
Component Id='C1' ...
File Id='R1' Keypath='yes' .../
... Id='R2'/
... Id='R3'/
/Component
For V2:
Preferred
1: Change ProductCode(s) (make this a major upgrade)
2: Force an updated version resource in R1 (sorry)
Component Id='C1' ...
File Id='R1' Keypath='yes' .../
!-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
!-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
!-- if R2 is a registry key --RemoveRegistryKey
Action='removeOnInstall'
.../
!-- you are out of luck if it us just a registry value --
... Id='R3'/
/Component
I can work on the extra credit latter...
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Monday, September 21, 2009 7:46 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Upgrade Installs and Component Rules
In version 1 of my application I have a component C1 which contains
multiple
resources.
C1 = { R1, R2, R3 }
The file R1 is the key path for C1.
The rest of the application requires that the resources are installed
with
the same path and names in V1 and V2.
In version 2 of my application I need to install a newer version of R3.
What's the right thing to do?
Version 2 of my application no longer needs R2.
What is the right thing to do?
(Extra credit: How does this change if R2 was the key path for the
component?)
The problems I'm having are that I can't change the name or path to the
resources because the application requires them to be found at a
particular
path - that's a pretty basic requirement that I don't think is
unreasonable.
That seems to mean that I can never split the resources into different
components and I can never remove a resource, because...
The component rules at
http://msdn.microsoft.com/en-us/library/aa367849(VS.85).aspx state:
Introduce a new component and assign it a unique component code when
making
any of the following changes:
- Any change that has not been shown by testing to be compatible with
previous versions of the component. In this case, you must also change
the
name or target location of every resource in the component.
- A change in the name or target location of any file, registry key,
shortcut, or other resource in the component. In this case, you must
also
change the name or target location of every resource in the component
Re: [WiX-users] Upgrade Installs and Component Rules
Further to what Blair says, you can check this topic:
http://msdn.microsoft.com/en-gb/library/aa368267(VS.85).aspx
This has some rather helpful flow diagrams that explain the logic
under a few different scenarios.
2009/9/23 Blair os...@live.com:
For V2:
1: Change ProductCode(s) (make this a major upgrade)
2: Make certain that C1 and C2 share the same condition and directory. In
the future, if you ever need them to have different conditions/directories,
you will be forced to rename R1 (placing the renamed R1 in some new
not-yet-created component and retire/remove C1 from your authoring
entirely).
Component Id='C1' ...
File Id='R1' Keypath='yes' .../
/Component
Component Id='C1-prime' ...
!-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
!-- if R2 is a registry key --RemoveRegistryKey Action='removeOnInstall'
.../
!-- you are out of luck if it us just a registry value --
... Id='R3'/
/Component
Blair
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Wednesday, September 23, 2009 6:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade Installs and Component Rules
And if R1 does not have a version resource? Most of the files involved will
not have version resources. They will be text/XML, arbitrary binary data,
or .jar files.
Scott
On Mon, Sep 21, 2009 at 2:19 PM, Blair os...@live.com wrote:
If you're reasonably certain that you will never need R2 again:
I assume V1 looks like this:
Component Id='C1' ...
File Id='R1' Keypath='yes' .../
... Id='R2'/
... Id='R3'/
/Component
For V2:
Preferred
1: Change ProductCode(s) (make this a major upgrade)
2: Force an updated version resource in R1 (sorry)
Component Id='C1' ...
File Id='R1' Keypath='yes' .../
!-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
!-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
!-- if R2 is a registry key --RemoveRegistryKey
Action='removeOnInstall'
.../
!-- you are out of luck if it us just a registry value --
... Id='R3'/
/Component
I can work on the extra credit latter...
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Monday, September 21, 2009 7:46 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Upgrade Installs and Component Rules
In version 1 of my application I have a component C1 which contains
multiple
resources.
C1 = { R1, R2, R3 }
The file R1 is the key path for C1.
The rest of the application requires that the resources are installed with
the same path and names in V1 and V2.
In version 2 of my application I need to install a newer version of R3.
What's the right thing to do?
Version 2 of my application no longer needs R2.
What is the right thing to do?
(Extra credit: How does this change if R2 was the key path for the
component?)
The problems I'm having are that I can't change the name or path to the
resources because the application requires them to be found at a
particular
path - that's a pretty basic requirement that I don't think is
unreasonable.
That seems to mean that I can never split the resources into different
components and I can never remove a resource, because...
The component rules at
http://msdn.microsoft.com/en-us/library/aa367849(VS.85).aspx state:
Introduce a new component and assign it a unique component code when
making
any of the following changes:
- Any change that has not been shown by testing to be compatible with
previous versions of the component. In this case, you must also change
the
name or target location of every resource in the component.
- A change in the name or target location of any file, registry key,
shortcut, or other resource in the component. In this case, you must
also
change the name or target location of every resource in the component.
- The addition or removal of any file, registry key, shortcut, or other
resource from the component. *In this case, you must also change the
name
or target location of every resource in the component.*
That last item to me says - you can't change components ever without
breaking your application. In what universe is it possible or practical
to
change the name or target location of every resource in the component
without breaking the application?
It seems that the only way to make an installer that can be upgraded is to
limit things to one resource per component. Is that right?
The component rules also state:
A new version of a component is assigned the same component code as
another
existing component. Modifying a component without changing the component
code is only optional in the following cases:
- The changes to the component have been proven by testing to be
backward
compatible with all previous versions of the component.
- The author can guarantee that the new version
[WiX-users] Upgrade Installs and Component Rules
In version 1 of my application I have a component C1 which contains multiple
resources.
C1 = { R1, R2, R3 }
The file R1 is the key path for C1.
The rest of the application requires that the resources are installed with
the same path and names in V1 and V2.
In version 2 of my application I need to install a newer version of R3.
What's the right thing to do?
Version 2 of my application no longer needs R2.
What is the right thing to do?
(Extra credit: How does this change if R2 was the key path for the
component?)
The problems I'm having are that I can't change the name or path to the
resources because the application requires them to be found at a particular
path - that's a pretty basic requirement that I don't think is unreasonable.
That seems to mean that I can never split the resources into different
components and I can never remove a resource, because...
The component rules at
http://msdn.microsoft.com/en-us/library/aa367849(VS.85).aspx state:
Introduce a new component and assign it a unique component code when making
any of the following changes:
- Any change that has not been shown by testing to be compatible with
previous versions of the component. In this case, you must also change the
name or target location of every resource in the component.
- A change in the name or target location of any file, registry key,
shortcut, or other resource in the component. In this case, you must also
change the name or target location of every resource in the component.
- The addition or removal of any file, registry key, shortcut, or other
resource from the component. *In this case, you must also change the name
or target location of every resource in the component.*
That last item to me says - you can't change components ever without
breaking your application. In what universe is it possible or practical to
change the name or target location of every resource in the component
without breaking the application?
It seems that the only way to make an installer that can be upgraded is to
limit things to one resource per component. Is that right?
The component rules also state:
A new version of a component is assigned the same component code as another
existing component. Modifying a component without changing the component
code is only optional in the following cases:
- The changes to the component have been proven by testing to be backward
compatible with all previous versions of the component.
- The author can guarantee that the new version of the component will
never be installed on a system where it would conflict with previous
versions of the component or applications requiring a previous version. For
more information, see What happens if the component rules are
broken?http://msdn.microsoft.com/en-us/library/aa372795(VS.85).aspx
.
The backward compatibility requirement only seems to matter if I allow the
older version of my application to be installed at the same time as the
newer version - which I do not want to allow. I think I can make the
guarantee in the second point - If MSI uninstalls the older
product completely before trying to install the newer one.
I do not want to allow multiple versions of the product to be installed at
the same time. I am using the VC 2005 runtime merge modules. That
apparently restricts when I am allowed to schedule the
RemoveExistingProducts action to places that preclude the option of my major
upgrade installer completely removing Version N before installing the files
for Version N+1.
Thanks in advance,
Scott
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Upgrade Installs and Component Rules
If you're reasonably certain that you will never need R2 again:
I assume V1 looks like this:
Component Id='C1' ...
File Id='R1' Keypath='yes' .../
... Id='R2'/
... Id='R3'/
/Component
For V2:
Preferred
1: Change ProductCode(s) (make this a major upgrade)
2: Force an updated version resource in R1 (sorry)
Component Id='C1' ...
File Id='R1' Keypath='yes' .../
!-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
!-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
!-- if R2 is a registry key --RemoveRegistryKey Action='removeOnInstall'
.../
!-- you are out of luck if it us just a registry value --
... Id='R3'/
/Component
I can work on the extra credit latter...
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Monday, September 21, 2009 7:46 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Upgrade Installs and Component Rules
In version 1 of my application I have a component C1 which contains multiple
resources.
C1 = { R1, R2, R3 }
The file R1 is the key path for C1.
The rest of the application requires that the resources are installed with
the same path and names in V1 and V2.
In version 2 of my application I need to install a newer version of R3.
What's the right thing to do?
Version 2 of my application no longer needs R2.
What is the right thing to do?
(Extra credit: How does this change if R2 was the key path for the
component?)
The problems I'm having are that I can't change the name or path to the
resources because the application requires them to be found at a particular
path - that's a pretty basic requirement that I don't think is unreasonable.
That seems to mean that I can never split the resources into different
components and I can never remove a resource, because...
The component rules at
http://msdn.microsoft.com/en-us/library/aa367849(VS.85).aspx state:
Introduce a new component and assign it a unique component code when making
any of the following changes:
- Any change that has not been shown by testing to be compatible with
previous versions of the component. In this case, you must also change
the
name or target location of every resource in the component.
- A change in the name or target location of any file, registry key,
shortcut, or other resource in the component. In this case, you must also
change the name or target location of every resource in the component.
- The addition or removal of any file, registry key, shortcut, or other
resource from the component. *In this case, you must also change the name
or target location of every resource in the component.*
That last item to me says - you can't change components ever without
breaking your application. In what universe is it possible or practical to
change the name or target location of every resource in the component
without breaking the application?
It seems that the only way to make an installer that can be upgraded is to
limit things to one resource per component. Is that right?
The component rules also state:
A new version of a component is assigned the same component code as another
existing component. Modifying a component without changing the component
code is only optional in the following cases:
- The changes to the component have been proven by testing to be backward
compatible with all previous versions of the component.
- The author can guarantee that the new version of the component will
never be installed on a system where it would conflict with previous
versions of the component or applications requiring a previous version.
For
more information, see What happens if the component rules are
broken?http://msdn.microsoft.com/en-us/library/aa372795(VS.85).aspx
.
The backward compatibility requirement only seems to matter if I allow the
older version of my application to be installed at the same time as the
newer version - which I do not want to allow. I think I can make the
guarantee in the second point - If MSI uninstalls the older
product completely before trying to install the newer one.
I do not want to allow multiple versions of the product to be installed at
the same time. I am using the VC 2005 runtime merge modules. That
apparently restricts when I am allowed to schedule the
RemoveExistingProducts action to places that preclude the option of my major
upgrade installer completely removing Version N before installing the files
for Version N+1.
Thanks in advance,
Scott
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX
