Chris I agree with you, MSIs forced into being platform specific is pretty ridiculous especially when taking .NET "AnyCPU" apps into account. I've been forced to write some workarounds for the WIN64DUALFOLDERS issue where I'm installing an x86 package to an x86 location but since the package is a plug-in which can be used with an x64 version of a 3rd party application, I have to hack around the Property modification in a Custom Action just to make the modifications to a .ini file required for the plug-in to show up in the x64 version of the 3rd party application. I would much rather be able to simply pass the .ini path to my Custom Action to make the required changes (thankfully after 4 years+ of people asking, the 3rd party application changed plug-in loading to use .addin files under CommonAppData instead of hacking a .ini file under the Installation Directory with their latest release so it's UAC compliant).
Windows Installer can be quite backwards in certain respects but it's also pretty forwards thinking in a lot of others compared to most non-MSI installation engines (e.g. transactional system/rollback). The Windows Installer team love to frustrate & infuriate us mere users it seems. They introduce features people have been requesting for years (e.g. hyperlink controls) but only add them into the latest version of the engine which is only available on the latest version of Windows. If a 4.5 redistributable is available for XP & later, there really is no reason other than some bullshit company policy why 5.0 can't be redistributed (it's not like Microsoft would try to force people to upgrade to newer versions of Windows by releasing crippled versions of their software for the older versions & then advertising it as such e.g. Internet Explorer). We all know the likelyhood of something like an "AnyCPU" platform for MSI's being supported in Windows Installer 5.1/5.5/6.0/whatever the next version is called is pretty low but if/when it does make it in, we'll be very lucky if it's available for anything other than Window 7/whatever the next version of Windows is as we all know. Having said all that, you can clearly see that my reply wasn't directed at, or to, you (or Travis & Rob M. for that matter). I was replying to the original query with advice on how the issue could be solved within the current systems limitations which was something I felt none of the replies so far had achieved. If you take umbrage to that then take it off list or put it in a blog post or something. Discussion is good but only in the right context & forum. 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: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: 20 September 2010 13:39 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to allow 32-bit installer to writetoC:\ProgramFiles And it's all a shame. I cane think of several use cases where it would be useful and approriate for MSI to support 32 and 64 bit components in a single install. To force seperation into multiple MSI's and logic into a setup.exe is just crazy. I should be able to do all of this with a single MSI. Take WiX for example ( and a related blog post that started all of this for me ) It's a 32bit application that has to work with a 32bit and 64bit API ( MSBuild ). Should WiX really have to have 2 different MSI's to download or 1 really complicated EXE with 2 MSI's inside of it? Should they really have to say "ah, 64bit is pretty rare anyways and the build engineer should be smart enough to copy the targets file from this directory to that directory ). A targets file is just a text file and there should be some way of telling MSI "yes, I really need to do that." My second use case is developing .NET applications. These are by default x86 OR x64 applications. There should be some way of telling MSI that it's AnyCPU and let MSI pick the best ProgramFilesFolder and registry location at runtime. Otherwise again you have to ship multiple packages or compile for x86 or risk registry bitness issues. My third case is VSTO AddIns. With Windows 7, one group within Microsoft eliminated Registry Reflection and another group introduced an x64 edition of Office while another group introduced VSTO 2010. The end result is some very interesting registry bitness problems ( see my recent blog post for more information ) that Windows Installer requires you to create 2 MSI's for to target the registry differently and it's not based on what the bitness of your application or your operating system is but really the bitness of the Office product you installed. Seriously, I've been doing Build / Install for 15 years now and I know what the hell I'm talking about. I don't need to hear things like "the official & recommended method..." or "highlight exploiting and undocumented". The official & recommended method is FAIL in my mind as it doesn't meet the real world use requirements. I've fought this battle with MSI vs .NET in the past and I won. I had to put up with blog articles like "No Managed Code CustomActions, no support on the way and here's why." but in the end I was proven right with introduction of DTF. It's alright, I'm rebellious and I'm patient. Eventually I hope their will be real progress from the Windows Installer team here. I just hope they downstream it all the way to atleast Vista when they do otherwise it becomes one of those "that's nice but doesn't help me at all" features. 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: Pally Sandher <pally.sand...@iesve.com> To: General discussion for Windows Installer XML toolset. <wix-users@lists.sourceforge.net> Sent: Mon, September 20, 2010 6:06:21 AM Subject: Re: [WiX-users] How to allow 32-bit installer to write toC:\ProgramFiles To answer Grant's query, the official & recommended method is that you need to use separate x86 & x64 packages. Windows Installer won't let an x86 package write to x64 file & registry locations as you've seen (logs will show WIN64DUALFOLDERS modifying any property which references an x64 location when running an x86 package). If you condition the x86 package with "NOT VersionNT64" it will be blocked for install on x64 systems (x64 packages can't be installed on x86 systems as you'd expect) which will give you 2 mutually exclusive packages. If you want to provide your users a single package for download you can use a bootstrapper such as dotnetinstaller (http://dotnetinstaller.codeplex.com/) to package both MSI's together & run the appropriate one for the users system. You can also use the same cab for both MSI's to reduce the file size if the files are identical (or have one main shared cab with separate x86 & x64 cabs containing only the files specific to that package). Just to clarify, this is a Windows Installer limitation not WiX. A package built with any MSI creation suite will have the same limitation, some will just go to great lengths to hide things like this from you (and charge an appropriate amount for the privilege). 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: 19 September 2010 22:21 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to allow 32-bit installer to write toC:\ProgramFiles I would like to highlight the words "exploiting" and "undocumented". I think they are very appropriate here. On Sat, Sep 18, 2010 at 11:19 AM, Christopher Painter < chr...@deploymentengineering.com> wrote: > I gave the short answer in a hurry. The longer answer ( found on a > blog exchange between Bob Arnson and myself ) involves using a custom > action to resolve the 64bit ProgramFilesFolder and then converting it > to a shortpath. > > > The magic wasn't in that part though. The magic is in exploiting the > undocumented behavior of MSI to fail to redirect short paths like it > does long paths. > > > 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: Travis Gaff <tra...@pc-doctor.com> > To: General discussion for Windows Installer XML toolset. > <wix-users@lists.sourceforge.net> > Sent: Sat, September 18, 2010 11:30:04 AM > Subject: Re: [WiX-users] How to allow 32-bit installer to write > toC:\Program Files > > That may not work on localized or non-standard installations. For > example, in Spanish C:\Program Files can become C:\Archivos de > Programas > > > CONFIDENTIALITY > The information contained in this message is confidential. It is > intended to be read only by the individual or entity to whom it is > addressed or by an authorized designee. If the reader of this message > is not the intended recipient, be aware that distribution of this > message in any form is strictly prohibited. If you have received this > message in error, please immediately notify the sender and destroy any copy of this message. > -----Original Message----- > From: Christopher Painter [mailto:chr...@deploymentengineering.com] > Sent: Friday, September 17, 2010 6:21 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] How to allow 32-bit installer to write > toC:\Program Files > > Officially it's not possible in a 32bit install but unofficially ( and at > your own risk ) I found a way. Convert the C:\Program Files to > C:\Progra~1 and you'll sneak past Windows Installer trying to "fix" it > for you. > > 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: garnold <grant.arn...@safe.com> > To: wix-users@lists.sourceforge.net > Sent: Fri, September 17, 2010 7:14:02 PM > Subject: [WiX-users] How to allow 32-bit installer to write to > C:\Program Files > > > Hi > > I am creating an installer that needs to install some .war files in a > servlet engine directory. In the installer, I am prompting for the > location of their installed servlet engine (for example, Apache > Tomcat). The problem occurs when they have a 64-bit computer with a > 64-bit servlet engine installed in "C:\Program Files". If they > specify in the browse dialog of our 32-bit installer to install those > files to "C:\Program Files\Apache\tomcat\webapps", then it will > actually change the directory to "C:\Program Files > (x86)\Apache\tomcat\webapps", where there is no Apache installed! I > understand that it is trying to be helpful in not allowing a 32-bit > app to be installed into Program Files, and for our main INSTALLDIR, > this is fine. However, for this prompt, I would like it to not have > this behaviour. > > Do you know of some way I can work around this so that the installer > won't change the "C:\Program Files" to "C:\Program Files (x86)" in this case? > > Thanks! > Grant > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-a > llow > -32-bit-installer-to-write-to-C-Program-Files-tp5544693p5544693.html<h > ttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-al > low-32-bit-installer-to-write-to-C-Program-Files-tp5544693p5544693.htm > l> > > Sent from the wix-users mailing list archive at Nabble.com. > > ---------------------------------------------------------------------- > ---- > ---- > Start uncovering the many advantages of virtual appliances and start > using them to simplify application deployment and accelerate your > shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > ---------------------------------------------------------------------- > ---- > ---- > Start uncovering the many advantages of virtual appliances and start > using them to simplify application deployment and accelerate your > shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > ---------------------------------------------------------------------- > -------- Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and accelerate > your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > ---------------------------------------------------------------------- > -------- Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and accelerate > your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- virtually, Rob Mensching - http://RobMensching.com LLC ------------------------------------------------------------------------ ------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
