I think you're all missing the point here. The issue is not where he installs his files to, his problem is writing to the registry.
Nate putting all your x86 & x64 DLL's in the same directory is fine. You can do this in both a x86 MSI and a x64 MSI. They can both install to the same path under "Program Files (x86)" if you so wish. You do not have to separate your x64 & x86 DLL's regardless of what people have been saying unless your application requires you to. What you cannot do is access the 64-bit areas of the registry from an x86 MSI (your x86 MSI will always be redirected to the Wow6432Node area). You can however access both the 32-bit and 64-bit areas of the registry from an x64 MSI but you can only install it on an x64 O/S. Hence if you want x86 O/S users to be able to install your application, you need to make an x86 MSI for them while the x64 O/S users use the x64 MSI. If you want to make changes to the 64-bit areas of the registry, author an x64 MSI. If you don't need to, stick with using a "one-size fits all" x86 MSI. 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: Blair [mailto:os...@live.com] Sent: 23 September 2009 02:43 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app That is an excellent idea. To extend it to a logical conclusion: All of the app (except for the shell extensions) goes under ProgramFilesFolder\"Company"\"Product" (and this is the directory that the user can change) The 32-bit shell extension always goes under CommonFilesFolder\"Company", and the 64-bit extension always goes under CommonFiles64Folder\"Company". You can use the $(sys.PLATFORM) value to exclude the 64-bit component from being compiled into your 32-bit MSI and you will be able to use the exact same sources for both the 32-bit and the 64-bit MSIs. -----Original Message----- From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: Tuesday, September 22, 2009 6:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app The way I've attacked this scenario is with two separate packages and a little bit of file duplication on the x64 system to prevent having to completely rework the application. No problems with the ICE tests either :) 32-bit system - everything gets installed to Program Files\ACME 64-bit system - 32-bit components get installed to Program Files (x86)\ACME - 64-bit components get installed to Program Files\Common Files\ACME - some files are duplicated between both the x64 and x86 locations to keep things simple, components marked as appropriate for the destination location. On Wed, Sep 23, 2009 at 10:26 AM, Blair <os...@live.com> wrote: > Heath has a really good blog post about what happens if you work with 64-bit > components in a 32-bit MSI package. The major limitation is that you > can't use a 64-bit directory since a Windows Installer supplied > directory reflection will always kick in on a 32-bit MSI. I found that > reading it about 5 times over several weeks leads to a better > understanding of what he > discovered vs. just one read-through. > > ICE80 is designed to make sure you don't build a 32-bit MSI that > accesses 64-bit regions of the OS (since your 32-bit app can't > normally reach them). > Have you run your Wise-generated MSI through either smoke or Orca's > validation? You will see the ICE80 error there if wise is generating a > 32-bit marked MSI. Just because Wise lets you doesn't mean it builds > "clean". > > You will need both 32-bit and 64-bit extensions installed on 64-bit > Oss, to > support 32-bit applications. > > The "correct" way is to build a 64-bit MSI for 64-bit OSs where all of your > components except for the 64-bit extension are 32-bit components, AND where > you place the 64-bit file in a 64-bit directory "by default". That > doesn't mean you don't allow the user to change the installation > locations, it just > means you have two installation locations (one for the 32-bit code and > one for the 64-bit code). You could force the 64-bit location to the > user's expressed preference IF the user changed it via a custom action. > > For just one component that writes one file and one registry key, that > may seem a bit much, however. Heath noted that a 64-bit component in a > 32-bit MSI will do two things: 1) the directory will be changed to the > matching 32-bit directory, and 2) the registry won't be changed (you > get the 64-bit registry). But, you will always get ICE80 issues when > you do that, since the > 32-bit directory isn't "supposed to" contain 64-bit code. > > One option is to build the 32-bit MSI with the 64-bit component. You > absolutely must add a "VersionNT64" condition on your 64-bit component > "GSIShell64" (there will never be any use of the 64-bit extension on a > 32-bit OS) and you will need to suppress the ICE80 during light and > ensure that you don't have any additional ICE80 errors or warnings in > subsequent builds by regularly running smoke (or Orca) on your MSI and > checking the results. It isn't "kosher" but it will work. > > I generally don't advocate this type of solution, but I also don't > view all > the ICE tests as written as always entirely practical either. You may > not be > able to get/retain a Logo doing this, since that requires a generally clean > ICE validation, so that should be weighed into your calculations. > > -----Original Message----- > From: Nate Hekman [mailto:hek...@geo-slope.com] > Sent: Tuesday, September 22, 2009 9:14 AM > To: WiX-users@lists.sourceforge.net > Subject: [WiX-users] Installing 64-bit shell extension with a 32-bit > app > > I have a 32-bit application that include a 32-bit shell extension dll > that handles thumbnails and a few other shell extensions. I want to > add a 64-bit version of that same dll to the mix to get the same > thumbnails et al working in 64-bit Windows Explorer. > > > > Can someone tell me (or point me to documentation) what the proper way > is to do this? > > > > Here's what I've been using for the 32-bit dll. The RegistryValue > line with [BINDIR] in the Value is the line that causes me trouble > when I get to 64-bit. > > > > <DirectoryRef Id="BINDIR"> > > <Component Id="GSIShell" > Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D"> > > <File Id="GSIShellDLL" Source="$(var.TargetDir)GSI.Shell.dll" > KeyPath="yes" Checksum="yes"/> > > <RegistryKey Root="HKCR" > Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}" > Action="createAndRemoveOnUninstall"> > > <RegistryValue Type="string" Value="GszIconShlExt Class"/> > > <RegistryKey Key="InprocServer32" > Action="createAndRemoveOnUninstall"> > > <RegistryValue Type="string" > Value="[BINDIR]\gsi.shell.dll"/> > > <RegistryValue Type="string" Name="ThreadingModel" > Value="Apartment"/> > > </RegistryKey> > > </RegistryKey> > > </Component> > > </DirectoryRef> > > > > [BINDIR] is defined earlier in the .wxs file as: > > > > <Directory Id="TARGETDIR" Name="SourceDir"> > > <Directory Id="ProgramFilesFolder"> > > <Directory Id="COMPANYDIR" Name="MyCompany"> > > <Directory Id="SOFTWAREDIR" Name="MyApplication"> > > <Directory Id="BINDIR" Name="Bin"/> > > </Directory> > > </Directory> > > </Directory> > > > > So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program > Files (x86)\MyCompany\MyApplication\Bin, and the Registry key > HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocSe > rv > er32's value is "C:\Program Files > (x86)\MyCompany\MyApplication\Bin\gsi.shell.dll". > > > > Then I add the 64-bit dll similarly. The file needs to be placed in > the same bin folder as the 32-bit version, but I want to be editing > the 64-bit portion of the Registry, so I add Win64="yes" to the Component. > > > > <DirectoryRef Id="BINDIR"> > > <Component Id="GSIShell64" > Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D" Win64="yes"> > > <File Id="GSIShell64DLL" > Source="$(var.TargetDir)GSI.Shell64.dll" KeyPath="yes" > Checksum="yes"/> > > <RegistryKey Root="HKCR" > Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}" > Action="createAndRemoveOnUninstall"> > > <RegistryValue Type="string" Value="GszIconShlExt64 Class"/> > > <RegistryKey Key="InprocServer32" > Action="createAndRemoveOnUninstall"> > > <RegistryValue Type="string" > Value="[BINDIR]\gsi.shell64.dll"/> > > <RegistryValue Type="string" Name="ThreadingModel" > Value="Apartment"/> > > </RegistryKey> > > </RegistryKey> > > </Component> > > </DirectoryRef> > > > > This gives me an error on the RegistryValue line with [BINDIR] in the > Value: > > > > Error LGHT0204: ICE80: This 64BitCompnent GSIShell64 uses > 32BitDirectory BINDIR. > > > > I've done a lot of googling and most responses are "you shouldn't be > installing 64-bit dlls with a 32-bit app". But that's absolutely not > true, as these dlls are used by the shell, not by my application. > There must be other people with this same problem. What's the solution? > > > > Thanks for any help! > > > > > > Nate ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
