On a 64 bit OS you'd probably want a second search with Win64=yes.
<Property Id="EXCELPATH32">
<RegistrySearch Id="ExcelDirSearch32" Root="HKLM"
Key="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe" Type="raw"
/>
</Property>
<Property Id="EXCELPATH64">
<RegistrySearch Id="ExcelDirSearch64" Root="HKLM"
Key="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe" Type="raw"
Win64="yes" />
</Property>
The 2nd RegistrySearch will probably give you an ICE80 *warning* for using a
64-bit RegistrySearch in a 32-bit package which you can suppress (or just
ignore if you don't have treat warning as errors on) but it should work on both
x86 & x64 systems.
-----Original Message-----
From: Shashank Padmanabhan (Aditi Technologies Private LTD)
[mailto:[email protected]]
Sent: Wednesday, April 24, 2013 9:59 AM
To: [email protected]
Subject: [WiX-users] WIN64DUALFOLDERS Issue - Installer modifying values
obtained from registry
Hi all,
I am using WIX and trying to read installed location of excel application from
Registry. Goal is to launch excel post install based on what the user chooses.
I obtain the same using a property below.
<Property Id="EXCELPATH">
<RegistrySearch Id="ExcelDirSearch" Root="HKLM"
Key="SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe" Type="raw"
/> </Property>
This obtains the appropriate path. But, it immediately modifies it on a system
with 64 bit OS with either of 32 or 64 bit 2013 excel. (It works on 12 other
combinations of Win7, Win8, Office 2007, Office 2010, Office 2013 all possible
combinations of 32 & 64 bit) Actual Value in Registry: "C:\Program
Files\Microsoft Office\..."
Modified Value by Installer: "C:\Program Files (x86)\Microsoft Office\..."
The obtained value in the property is now no longer valid, since it has the
extra ' (x86)' characters in it.
I searched around and came across this
link<http://www.mentby.com/Group/wix-users/registrysearch-converts-value-data.html>,
where it was suggested to use a custom action to modify the value. We used a
custom action to modify the property. But we found that the value is not
reflected when the final dialog tries to launch excel on its exit.
Additionally, I also tried this. Instead of using EXCELPATH directly to launch
excel, I created a dummy property, set it in the custom action and then tried
to use to launch excel using that.
<Property Id="ACTUAL_EXCELPATH">
</Property>
Interestingly we found that the property value was being set as per the custom
action and was available only until 'InstallFinalize' event. It was cleared out
by the time the final dialog was using it to launch excel! (See attached log
file) When we hard coded ACTUAL_EXCELPATH property value to the actual value in
registry, it remained available after 'InstallFinalize' event.
What do I need to do to fix this issue?
Note:
Also, one weird thing I observed. I quadruple checked this.
Win8 64 bit, 2013 32 bit office points to 64 bit programs files location. So is
the same with registry value at 'CurrentVersion\App Paths\excel'.
Win8 64 bit, 2013 64 bit office points to 64 bit programs files location. So is
the same with registry value at CurrentVersion\App Paths\excel.
A little perplexed that 32 & 64 bit versions of office are both at the same
program files location (Installed 2 different PC's). Location being -
"C:\Program Files\Microsoft Office\...". The 32 bit version of office should
have installed at "C:\Program Files (x86)\Microsoft Office\..."!
Thanks,
Shashank
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
_______________________________________________
WiX-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
