The core problem here is something you've highlighted already yourself Rob in your earlier post. Windows Installer is repeatedly & vehemently inconsistent (consistently inconsistent?). As you state, it quite happily recognises 4 version fields for File versions but Products are limited to 3. As per Neil's experience we've had to choose an approach which best suits both our versioning requirements & what Windows Installer will work with due to the inconsistency.
In most other 'platforms', when issues of this ilk are uncovered they tend to be addressed by the developers. Unfortunately as we've all experienced over the years, this isn't how Microsoft treats Windows Installer to all our detriment. Palbinder Sandher Software Deployment & IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the <Virtual Environment>** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -----Original Message----- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 17 January 2011 02:47 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix upgrade process does not consider 4th part of the version string I saw you're reply later and was going to get to it later (er, now). <smile/> Personally, I would chose to have an error that says, "An equal version of this product is installed. Remove it first, before installing." Maybe with a bit better error message. The lack of 4th version in the installer does make standard CI difficult. I guess I would just push the error up rather than hide the issue and have the mysterious behavior of "The installer just downgraded me today." Maybe you've trained your users (QA only?) and have other systems in place to prevent the badness of downgrade (aka: versioning gone wrong) in check. Maybe the CI adds enough value to deal with the issues. In my experience, the trade-offs don't work and most people don't think through the full repercussions, leading to bad places. Neil, you certainly pay attention to the details and I'm possibly just jaded. This is just my point of view. <smile/> Finally, I agree that the Windows Installer is the best of the alternatives thus far. On Sun, Jan 16, 2011 at 2:09 PM, Neil Sleightholm <n...@x2systems.com>wrote: > >> PS: If you don't thinking versioning is that important to your > product then you probably think I'm over exaggerating the issue. > > 100% agree, version is 'the' most important thing I do. I know you > replied to Chris but I thought I'd add my comments... > > This is why I have had to choose the approach I outlined. I choose to > schedule RemoveExistingProducts after InstallValidate for exactly the > same reason, remove everything then put it back, that way I can get > around the Windows Installer limitations. I choose Windows Installer > because it helps more than hinders - I would love to use a product > that did everything I need but it doesn't exist. I accept the > limitations but there is no alternative but to work around them. > > May be I am missing the point but surely the WiX install has adopted > the same approach, you just happen to set part 4 to 0 and don't > release two versions on the same day. If you have continuous > integration system I am struggling to see an alternative. > > Neil > > -----Original Message----- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: 16 January 2011 18:12 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Wix upgrade process does not consider 4th > part of the version string > > Oh, I can't justify the Windows Installer choice either. I also can't > change it. > > Software engineering is fun because we can build our own Lego blocks > to build what we want to build. Remember 30 years ago how hard it was > to build smooth looking things with Legos? The parts just did not > exist (they kinda' > do now, pretty cool). > > In software we get to build our own parts. > > *Except* when we choose to use some platform. Then the platform > dictates certain things to be true. The rules of gravity if you like. > The Windows Installer (for whatever reason, I really don't know) chose > that only the first 3 parts of the ProductVersion would be evaluated. That's it. > That's gravity. We can request that they change the rule but until the > rule changes, that's it. > > Now, many software engineers don't like to accept limitations. We know > we could alwasy build our own blocks. Most software engineers > particularly disdain limitations that have no value or *negative* value. > Sometimes creative solutions can even provide solid work arounds with > no ill side-effects. However, messing with versioning is terrifying to > me because versioning is the very foundation for software engineering > and especially vital for *setup* development. Get versioning wrong and > you end up with non-working systems (particularly with the Windows > Installer). > > Maybe I'm sensitive to the issue because I've just seen so many > problems foisted upon our customers because some setup developer > didn't think the rules had to apply him or her. Maybe in controlled > environments, the setup developer can control the larger system to not > worry about the inconsistent versioning rules that > @AllowSameVersionUpgrade creates. I just don't have enough faith in > large systems (I personally usuall have to deal with > *extremely* large systems) to remain constant to mess with versioning > like that. > > And ultimately, I have to ask, "To what end?" Are we trying to bend > the monolithic Lego piece that is the Windows Installer to show it > that we can? > Are we trying to demonstrate that we think 3 part versioning is > incredbily lame and that we are willing to pay the cognitive > dissonance tax of messed up product versioning to show it? > > That's not worth it to me. I believe versioning (how ever many dots > are > involved) is too important to software engineering and setup > development to play games. > > Thankfully, the Windows Installer understands 4 part file versions. > <wink/> > > PS: If you don't thinking versioning is that important to your product > then you probably think I'm over exaggerating the issue. > > On Sun, Jan 16, 2011 at 9:18 AM, Christopher Painter < > chr...@deploymentengineering.com> wrote: > > > Rob- > > > > The comment to not use MSI aside, it is pretty hard for me to > > justify to build engineers, software developers and product managers > > that yes they can build DLL's as 1.0.0.0 and 1.0.0.1 but that they > > can't build their MSI as 1.0.0.0 and 1.0.0.1 because MSI will see it > > as 1.0.0 and 1.0.0. > > > > I'm pretty much left saying "you are right, that is the tail > > wagging the dog. > > But that's the framework we use so deal." > > > > I'd appreciate your detailed thoughts on this. > > > > Chris > > > > Christopher Painter, Author of Deployment Engineering Blog Have a > > hot tip, know a secret or read a really good thread that deserves > > attention? E-Mail Me > > > > > > > > ----- Original Message ---- > > From: Rob Mensching <r...@robmensching.com> > > To: General discussion for Windows Installer XML toolset. > > <wix-users@lists.sourceforge.net> > > Sent: Sun, January 16, 2011 10:55:00 AM > > Subject: Re: [WiX-users] Wix upgrade process does not consider 4th > > part of the version string > > > > Terrifying. You must be in some really controlled environments for > > that to work out well. <smile/> > > > > The Windows Installer (for whatever reason) chose to ignore the 4th > > version. > > It boggles my mind that "management" gets to decide a versioning > > scheme that won't work. You might as well pick a different > > installation technology that meets the requirement than the Windows > > Installer if something so fundamental as versioning is going to be > > ignored. > > The cognitive dissonance here kills me. <smile/> On Sun, Jan 16, > > 2011 at 7:07 AM, Neil Sleightholm <n...@x2systems.com > > >wrote: > > > > > I have a similar scenario and my workaround is to allow same > > > version > > > > upgrades. This means 3.0.1.14900 will upgrade 3.0.1.14500 (but it > > > also means 3.0.1.14500 will upgrade 3.0.1.14900 which might be > undesirable). > > > > > > In WiX 3.5 you can do this by setting > > > MajorUpgrade/@AllowSameVersionUpgrades - otherwise just set the > > > appropriate fields in the Upgrade table. > > > > > > Neil > > > > > > -----Original Message----- > > > From: Sanjay Rao [mailto:s...@noida.interrasystems.com] > > > Sent: 14 January 2011 21:33 > > > To: General discussion for Windows Installer XML toolset. > > > Subject: [WiX-users] Wix upgrade process does not consider 4th > > > part of the version string > > > > > > Hi, > > > > > > I have an installer having 4-part version strings. Our installer > > > stops installation if a newer version is already installed on the > > > system. We often have alpha/beta releases of our product in which > > > we > > > > do not change first 3 parts of the product. Suppose we have two > > > releases of our product : > > > Release1 : 3.0.1.14500(Alpha) > > > Release2 : 3.0.1.14900(Beta) > > > > > > Our users are able to install alpha release even if beta is > > > already present on their systems. > > > I went through this article > > > http://wix.sourceforge.net/manual-wix3/major_upgrade.htm > > > see the paragraph having text "Windows Installer only uses the > > > first > > > > 3 parts of the............" > > > > > > Is there any way in Wix to take care of 4th part of version string > > > in upgrade process ? > > > OR > > > Do I need to dive into clumsy custom action thing to take care > > > this > ? > > > > > > Regards, > > > Sanjay Rao > > > > > > -- > > > Sanjay Rao > > > Digital Media Group, Interra Systems s...@interrasystems.com > > > Phone: +1-408-873-1212 > > > http://www.interrasystems.com > > > > > > ------------------------------------------------------------------ > > > -- > > > ---- > > > ------ > > > 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 > > > WiX-users@lists.sourceforge.net > > > 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 > > > WiX-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > > > > -- > > virtually, Rob Mensching - > > http://RobMensching.com<http://robmensching.com/>LLC > > > ---------------------------------------------------------------------- > -- > ------ > 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 > WiX-users@lists.sourceforge.net > 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 > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------ ------ 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 WiX-users@lists.sourceforge.net 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 WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
