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 BlackBerry® 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-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
