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 > > 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
