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\Setu
p\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
