Regarding paragraph three... I don't have any trouble with my product/upgrade codes working. They are all set and upgrades to specific products work great.
The trouble is that I need to upgrade a file that is shared between about 30 *different* installers. It's a common dependency between these different products and my most recent product (not an upgrade to an existing product) has an updated, but backward compatible version of this file. As you said, if this was a Dll it would be possible via versioning. It's a bit frustrating that I can't do this with a non PE binary file... not sure how I'm going to move forward since I have a ton of the products containing the version 1.0 files in the field already. Anyway, thanks for taking the time to explain it to me. At least I understand the limitations of the Windows installer now. Craig On Tue, Jul 6, 2010 at 11:00 PM, Blair <os...@live.com> wrote: > Only PE binary files (normally .EXE, .DLL, .OCX, .SYS, etc.) files carry > version resources that Windows Installer knows about. Other file types > (.TXT, .INI, .XML, .CAB, etc.) files that are not PE binary files can't have > the version resource Windows Installer knows how to read and have to use the > rules that the documentation describes > > It all depends on the content of file you are upgrading. The links I > supplied to you supply the documentation regarding how Windows Installer > makes file upgrade determinations. If you "lie" to Windows Installer about a > file that can't supply its own version information to Windows Installer, you > may be able to force a particular behavior during initial installation, but > you will get repairs and possible prompts for source whenever a "health > check" occurs for any feature your files components are in, which leads to a > terrible user experience, a bunch of "missing component" system log entries, > and pop-up Windows Installer repair dialogs, and the same behavior you > intended for installation will be repeated during repairs. Using the > DefaultVersion attribute is usually ill-advised. > > Usually it is considered best practice to have written installers such that > they either refuse to install or exit with a success code without actually > installing when an installation package with a higher version and the same > UpgradeCode is already installed. Of course, that requires that the package > already installed on the box was coded that way, so if it is re-presented > for installation it won't overwrite a future package. > > Otherwise, you should always replace every file no matter what on every > installation (allowing complete downgrades) to prevent mixed version > installations. > > Blair > > -----Original Message----- > From: Miller, Craig [mailto:craig.mil...@spatialminds.com] > Sent: Tuesday, July 06, 2010 9:16 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Component Level Versioning? > > Anyone know how I can set a file version? > > I read through the links that Blair provided and I believe setting > the file version of my new files is the best way to move forward. > > My understanding is that I need to specify the file version in my new > installers. This will: > 1. Insure that the existing files with a hash but no version are upgraded > 2. More importantly, insure that these upgraded files aren't > overwritten when an older installer w/o file version info is run after > the new installer. > > I could use the "DefaultVersion" attribute of the file element and use > the suppress files option in "light", but this would suppress the file > version of all files. It seems like the best way to move forward is > to specifically set the file version of my updated files. > Unfortunately, I can't figure out how to do that, which leads me to > the question.... > > "Anyone know how I can set a file version? > > Thanks, > Craig > > On Wed, Jun 30, 2010 at 2:08 PM, Blair <os...@live.com> wrote: >> With regards to files that don't have Version resources (since WiX's > binder >> by default does populate the file hash for files that don't contain > version >> resources) the following pages are of use to help you understand what is >> expected. >> >> The default behavior for your case is described on this page: >> http://msdn.microsoft.com/library/aa370532.aspx >> >> REINSTALLMODE is described here: >> http://msdn.microsoft.com/library/aa371182.aspx >> >> The default value for REINSTALLMODE is documented as "omus". >> >> Additional information about file replacement rules (versioning) covering >> additional cases is found in the same area of the MSDN library. >> >> -----Original Message----- >> From: Miller, Craig [mailto:craig.mil...@spatialminds.com] >> Sent: Wednesday, June 30, 2010 11:55 AM >> To: General discussion for Windows Installer XML toolset. >> Subject: Re: [WiX-users] Component Level Versioning? >> >> Thanks Peter and Pally for the replies. >> >> I don't make a lot of installers, but I did read and follow the >> component rules very carefully when I created the original installer. >> What I'm unclear on is if I have the same component snippet in two MSI >> files (same GUID), but one snippet contains a newer version of the >> underlying file, how does the windows installer know that the newer >> version is in fact a newer version? >> >> E.g. >> Version 1 created in 2008 and Version 2 created in 2010 are identical >> except the "Source" attribute of the "File" element points to an >> updated version of the file "..\USGS >> Topographic\250k\NY\c43078a1.tif". Since components don't appear to >> have any version info, if I run the version 2 installer, followed by >> the version 1 installer, what prevents the old file from overwriting >> the newer file? >> >> <Component Id='c43078a1.tif' Guid='784351B6-50BC-43B3-B668-F5248B4A4B90'> >> <File Id='c43078a1.tif' >> Name='c43078a1.tif' DiskId='1' >> KeyPath='yes' >> Source='..\USGS Topographic\250k\NY\c43078a1.tif' /> >> </Component> >> >> >> Agreed, VMs are very helpful for this sort of thing. >> >> Craig >> >> >> >> > ---------------------------------------------------------------------------- > -- >> This SF.net email is sponsored by Sprint >> What will you do first with EVO, the first 4G phone? >> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first >> _______________________________________________ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> > > > > -- > Craig Miller > Geospatial Software Architect > > ---------------------------------------------------------------------------- > -- > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Sprint > What will you do first with EVO, the first 4G phone? > Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Craig Miller Geospatial Software Architect ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
