Hi, This is not a better solution at all. Sometimes user can support same version upgrade. On the other times he can have support of modifying the existing installation using installer. We cannot stop installation in case of same version.
Regards, Sanjay Rao On 16-01-2011 18:47, Rob Mensching wrote: > 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 >> >> > -- 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
