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}\InprocServ > 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 > > > ------------------------------------------------------------------------------ > 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 > ------------------------------------------------------------------------------ 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
