Sorry, this will be rushed. I'm about to disappear. 1. "Because 32-bit components cannot be installed to a 64-bit Program Files folder" There's no reason you can't put 32-bit files in a 64-bit location (in a 64-bit installer). The separation is a convention. Or am I misunderstanding ?
2. Search "persisting" & "properties". Add some of that to your wixlib. User-selected directory locations always need this so it's a common question on the list. -----Original Message----- From: Sean Dockery [mailto:dockerys...@gmail.com] Sent: 27 June 2011 14:45 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Installing WiX library to different location,recalling location on modify/uninstall Thanks, Peter, for the prompt reply. I had previously gotten as far as you have described. I realized in re-reading my original post that I wasn't as clear about the problem as I should have been. Specifically, in my situation the WiX library contributes 32-bit components, which may or may not be installed to the same location as the 64-bit product's component. In the case of the 32-bit product, these sets of components will always be installed to the same location. So, this is how things appear in the 64-bit product installer project... wixlib: <Wix...> <Fragment> <DirectoryRef Id="LIBINSTDIR"> <Component Id="LibComponent" ...> ... </Component> </DirectoryRef> </Fragment> </Wix> product: <Wix...> ... <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="ProgramFiles64Folder"> <Directory Id="PRDINSTDIR" Name="CompanyName"> <Component Id="PrdComponent" ...> ... </Component> </Directory> </Directory> <Directory Id="ProgramFilesFolder"> <Directory Id="LIBINSTDIR" Name="CompanyName" /> </Directory> </Directory> <Feature Id="ProductFeature" Name="Product Name" ConfigurableDirectory="PRDINSTDIR" Display="expand" Level="1"> <ComponentRef Id="PrdComponent" /> <Feature Id="LibraryFeature" Name="Library" Display="hidden" Level="1"> <ComponentRef Id="LibComponent" /> </Feature> </Feature> ... <UIRef Id="WiXUI_FeatureTree" /> ... </Wix> Because 32-bit components cannot be installed to a 64-bit Program Files folder, the root folder into which these components are installed are necessarily different _when the default location is accepted_. However, when the user chooses to customize the install location of the product, if the target location is _not_ under the ProgramFiles64Folder, it is required that the 32-bit components and 64-bit components be installed to the same target location. For example, either in parallel directories like this... - PRDINSTDIR = C:\Program Files\CompanyName - LIBINSTDIR = C:\Program Files (x86)\CompanyName ...or in a single directory like this... - PRDINSTDIR = LIBINSTDIR = C:\SomewhereElse\CompanyName So, I have two different problems. 1st, I need to be able to dynamically derive the value of LIBINSTDIR based on PRDINSTDIR. That is, if the value of PRDINSTDIR is subordinate to [ProgramFiles64Folder], then LIBINSTDIR should be installed to a parallel location under [ProgramFilesFolder]. And if PRDINSTDIR falls outside of [ProgramFiles64Folder], then LIBINSTDIR can install to the same location. I expect that I will need to use some inline VBscript or similar to program this behaviour in a custom action during the UI sequence. 2nd, I need to apply the dynamic value of LIBINSTDIR in such a way that it is recalled by the WiX library contributed components when they are uninstalled. I thought that a type 51 custom action would achieve this, but I think that it needs to be called earlier than before "InstallFiles". That is why I was wondering how "early" it could be called; I was proposing to do it immediately following "AppSearch" and wondered if there may be any problems in doing so. I assumed, too, that the directory identifiers needed to be public properties (i.e.: all uppercase) to allow them to breach the UI/execute barrier -- but perhaps having them breach the UI/execute barrier isn't necessary? Any advice you (or anyone else, for that matter) can offer is welcome. PS: I'm using WiX 3.5, if that matters. It appears that the install sequence described in the Nick Ramirez WiX book does not match the install sequence in WiX 3.5 in all cases. I suspect that this is a consequence of the UI that I'm selecting, however; but I don't know enough about WiX (yet) to be sure. -----Original Message----- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: June 27, 2011 03:03 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing WiX library to different location, recalling location on modify/uninstall A simple wixlib looks something like this. There are some components under a directory ref and they are gathered into a component group. <Wix...> <Fragment Id="TestWixLib"> <DirectoryRef Id="LIB_Dir"> <Component> <File Id="LIB_test.txt" Source="test.txt" /> </Component> ...more components </DirectoryRef> <ComponentGroup Id="LIB_Components"> <ComponentRef Id="LIB_test.txt " /> .. more componentrefs </ComponentGroup> </Fragment> </Wix> To use this wixlib, reference the component group in a feature and define a directory alias where you want the files to be. <Wix..> <Product...> <Feature Id="Main" ..> <ComponentGroupRef Id="LIB_Components" /> .. other product components... </Feature> <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="ProgramFilesFolder"> <Directory Id="CompanyProgramsDir" Name="PLC"> <Directory Id="ProductDir" Name="FunkyProduct"> <Directory Id="LIB_Dir" /> <!-- A dir with no name is just an alias for the containing directory element --> </Directory> </Directory> </Directory> </Directory> </Product> </Wix..> -----Original Message----- From: Sean Dockery [mailto:dockerys...@gmail.com] Sent: 27 June 2011 07:11 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Installing WiX library to different location,recalling location on modify/uninstall Hello everyone, I am in the midst of porting an InstallShield InstallScript for MSI project to WiX and I've run into a little trouble. I'm new to WiX and not terribly knowledgeable about Windows Installer, so please forgive me if I'm asking a question for which the answer seems obvious. In my effort to port one of our merge modules to a WiX library, I need to install the content of the WiX library to a custom location - but not the same location as the main product project. I have followed the example on page 125 of Nick Ramirez's book on WiX, in which a type 51 custom action is used to set the AppDataDir property before the "InstallFiles" sequence in the InstallExecuteSequence. The files install to the dynamic location, but - unfortunately - it appears that these components do not remember where they were installed and removing the entire product results in the WiX library contributed files to remain when installed to a non-default location. Is the problem merely that the type 51 custom action should be called earlier in the install execute sequence? For example, should it be set immediately after the AppSearch sequence? Best regards, Sean ---------------------------------------------------------------------------- - - All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. ---------------------------------------------------------------------------- -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ----------------------------------------------------------------------------- - All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
