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
