Why not just add two RegistrySearch elements, one looking in the
WOW6432Node, and one in the standard location. If Windows Installer
can't find the first location it will look in the next.
________________________________
From: Ross Holder [mailto:[EMAIL PROTECTED]
Sent: 23 May 2008 14:27
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Visual Studio 2008 Extensibility: Detection &
Beyond
Today has been quite a day. It began with me debugging a .wxs file
whose build logs and pertinent documentation seem to be demonstrating
reticence concerning detection and acquisition of strings related to an
install of Visual Studio 2008. Surprised? I sure was! First a quick
review (skip to the subheading "The Problem...", below, if you know
everything concerning Properties, Directory tags, and Folder detection
with RegsitrySearch):
Use Properties to Acquire Directory Handles
When using WiX, there appears to be an established best practice
<http://www.dalun.com/wix/04.25.2007.htm> of:
* creating a <Property.../> node to contain a
<RegistrySearch.../> node with the Name and Key attributes referencing a
registry key that contains the name of the installation path,
* creating a <Condition... /> node which has a Message attribute
containing the failure message, should the condition described between
the start and end markers not be met, and
* using the <Property Id="{value}"> node's Id attribute {value}
as the Id attribute for a new <Directory... /> tag.
In fact, this approach works pretty well from what I've found. This
same .wxs file I'm working on already successfully detects two other
software titles (one of which is the .NET Framework v3.5):
23 <!-- Detect .NET Framework -->
24 <Property Id="FRAMEWORK35">
25 <RegistrySearch Id="Framework35Reg" Type="raw" Root="HKLM"
Key="SOFTWARE\Microsoft\NET Framework Setup\NDP\v3.5" Name="Install" />
26 </Property>
27
28 <Condition Message=".NET Framework 3.5 is not present on the
computer.">
29 FRAMEWORK35 = "#1"
30 </Condition>
Registry Keys and x64 Installation
Although I'm told WiX tries to make provisions for 64-bit installation
(and builds of installers on this platform), the reality is we still
have a few issues where 64-bit installers are concerned. If we look a
line 25 in the above example, we see a <RegistrySearch...> Key
attribute that doesn't exhibit any x64 characteristics. However, this
changes when we try to detect Visual Studio's Program folder:
33 <!-- Detect VS2008 -->
34 <Property Id="VSTUDIODETECT">
35 <RegistrySearch Id="VStudioReg" Type="raw" Root="HKLM"
Key="HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\
Setup\VS" Name="ProductDir" />
36 </Property>
As you can see highlighted above on line 35, we encounter such a Key
attribute.
The Problem....
...is twofold:
For some unknown reason, all of the registry keys which contain Visual
Studio 2008 information that we've tried to apply to the above approach
have failed! The Condition block that we've attempted to use with the
detection is:
38 <Condition Message="This product extends Visual Studio 2008,
which was not found. Installation of Visual Studio features will not
continue (but the remaining features will).">
39 VSTUDIODETECT
40 </Condition>
Seems simple enough. (Also tried using "VSTUDIODETECT = "#1" " on line
39, but with absolutely no measurable difference in the results.) The
MSI log output only offers the following:
1 === Logging started: 5/22/2008 16:41:37 ===
2 Action 16:41:37: INSTALL.
3 Action start 16:41:37: INSTALL.
4 Action 16:41:37: PrepareDlg.
5 Action start 16:41:37: PrepareDlg.
6 Info 2898. For WixUI_Font_Normal textstyle, the system created a
'Tahoma' font, in 0 character set, of 13 pixels height.
7 Info 2898. For WixUI_Font_Bigger textstyle, the system created a
'Tahoma' font, in 0 character set, of 19 pixels height.
8 Action 16:41:37: PrepareDlg. Dialog created
9 Action ended 16:41:37: PrepareDlg. Return value 1.
10 Action 16:41:37: AppSearch. Searching for installed applications
11 Action start 16:41:37: AppSearch.
12 AppSearch: Property: PROPERTY1, Signature: Property1Reg
13 AppSearch: Property: FRAMEWORK35, Signature: Framework35Reg
14 AppSearch: Property: VSTUDIODETECT, Signature: VStudioReg
15 Action ended 16:41:37: AppSearch. Return value 1.
16 Action 16:41:37: LaunchConditions. Evaluating launch conditions
17 Action start 16:41:37: LaunchConditions.
18 This product extends Visual Studio 2008, which was not found.
Installation of Visual Studio features will not continue (but the
remaining features will).
19 MSI (c) (6C:70) [16:41:38:237]: Product: Sonora 1.0 -- This
product extends Visual Studio 2008, which was not found. Installation
of Visual Studio features will not continue (but the remaining features
will).
20
21 Action ended 16:41:38: LaunchConditions. Return value 3.
22 Action 16:41:38: FatalError.
23 Action start 16:41:38: FatalError.
24 Action 16:41:38: FatalError. Dialog created
25 Action ended 16:41:39: FatalError. Return value 2.
26 Action ended 16:41:39: INSTALL. Return value 3.
Visual Studio 2008, like its predecessors, creates many registry keys
during its own installation. However, there are none which are both:
* a non-x64 key, and
* contain the string "{Drive}:\Program Files\Microsoft Visual
Studio 9.0\"
This is probably because specification of the Program folder is actually
relevant to x64/x86 architecture selection (i.e. "Program Files"
typically becomes "Program Files (x86)" for 32-bit apps when installed
to 64-bit platforms), and Visual Studio 2008 is a 32-bit app.
But one of the goals of our installer is to detect the Visual Studio
2008 Program folder so we can add some files to the Xml\Schemas
subfolder therein. Although, right now even detection of VS 2008 is
failing even using the string above, or any other strings which fall
outside of the Wow6432Node in the registry! (Yes, we've tried using
other keys than the one cited on line 35 in the example above.)
Solution?
A couple of workarounds have been proposed: we could use
$var.{ProjectName}.Platform variables in concert with both <?define...
?> variables and solution configurations, both on the build server and
in VS2008 to substitute static strings. This assumes:
* VS2008 is always installed to the "{Drive}:\Program Files
(x86)\Microsoft Visual Studio 9.0\" or "{Drive}:\Program Files\Microsoft
Visual Studio 9.0\" folder, and
* that we can figure out a way to substitute {Drive} in the
above string wherever is appropriate in a .wxs file - so far, I don't
see how that can be achieved.
The second workaround would involve simply taking one of the non-x64/x86
registry keys and appending a "..\.." however many times to get back up
to the Program folder (since there are registry keys which specify
VS2008 subfolders outside the Wow6432Node). But apart from this being
kind of messy, there's still the serious issue of even getting past the
point of detecting Visual Studio 2008.
Any and all help/suggestions are appreciated!
RH
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
