If you are willing to suppress a couple of ICE tests during your build (I
once imposed a rule that every MSI that my team had any responsibility for
must have ALLUSERS set to 1 and no references to HKCU could exist in the
Registry table) you can accomplish both items in your list by doing the
following:
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLDIR" Name="My Program" />
</Directory>
<Directory Id="ProgramMenuFolder">
<Directory Id="ProgramMenuDir" Name="My Program Suite" />
</Directory>
</Directory>
<Property Id="ALLUSERS" Value="1" />
<Condition Message="Per-User installations are not supported">Installed OR
ALLUSERS=1</Condition>
<Feature ...>
<Component Id="MyExeComponent" Feature="ProductFeature"
Directory="INSTALLDIR" Guid="*">
<File KeyPath="yes" Source="MyProgram.exe" />
</Component>
<Component Id="MyStartMenu" Feature="ProductFeature"
Directory="ProgramMenuDir" KeyPath="yes"
Guid="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx">
<Condition>STARTMENU</Condition>
<CreateFolder />
<RemoveFolder Id="StartMenu" On="uninstall"/>
<Shortcut Id="StartMenu" WorkingDirectory="INSTALLDIR"
Target="[INSTALLDIR]MyProgram.exe" Name="My Program" />
</Component>
</Feature>
Then, in your project settings (or your light.exe commandline, depending on
your build system) you suppress ICE38 and ICE43.
Here's the rational: Both ICE38 and ICE43 (along with a lot of others) make
some (often invalid) assumptions. One of those assumptions is that any
system-defined directory that COULD be in the user profile WILL BE in the
user profile. This is because you can override the ALLUSERS setting from the
Property table (including removing it) using the commandline and/or some
custom action, and the ProgramMenuFolder directory CAN be in the user
profile (when ALLUSERS isn't set [to 1]). ICE43 specifically tests
components containing non-advertized shortcuts for HKCU keypaths (which is
only a valid [IMHO] requirement when installing to a user's Start menu), and
ICE38 looks at components that make use of (in various specific ways)
subfolders of known folders that could be in the user profile.
If you suppress these ICE tests, it is always a good idea to periodically
review (using either smoke or orca, or some other validation tool) your MSIs
making sure that there are not issues with other components relative to
those ICE tests. Note that the WiX toolset routinely suppresses/ignores
ICE33 and ICE66 (for various historical or other reasons).
The code I illustrate is safe for per-machine installations (which is why
the ICE tests can be ignored for the MyStartMenu component). If your code
differs materially from my example, you will need to understand what your
code is doing and what effects it will have under different
situations/platforms/etc. You should also always prevent things you
explicitly don't support (such as attempted per-user installations of
per-machine packages) by blocking installation (such as testing for ALLUSERS
being overridden as I have in the example code above).
Blair
-----Original Message-----
From: Ivo Beltchev [mailto:i...@roadrunner.com]
Sent: Saturday, July 03, 2010 7:29 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Question about Start Menu shortcuts
Hi
I have an installer with 2 features. Each feature has an EXE. I only
allow per-machine installation, and not per-user.
I want to create a folder in All Users\Start Menu\Programs, which
contains shortcuts to both EXEs. I also want to make that folder
optional, with a property controlled by a checkbox in the CustomizeDlg.
I am faced with 2 problems:
1) I added a Directory "ProgramMenuFolder", another Directory inside it
"ProgramMenuDir" and a Component with a RemoveFolder item (on
uninstall). I followed the instructions in the tutorial, with the
exception that I didn't copy the RegistryValue member of the Component.
Light is giving me an error "ProgramMenuDir installs to user profile. It
must use a registry key under HKCU as its KeyPath". But the thing is I
want to install to the global Programs menu, not the user-specific (my
ALLUSERS is set to 1). Why is it asking to write to HKCU? Maybe instead
of ProgramMenuFolder I should be using something like
CommonProgramMenuFolder?
BTW, even if I add the HKCU key path, I get an error later in the
component that contains the shortcut: "ICE43: Component Blah has
non-advertised shortcuts. It should use a registry key under HKCU as
its KeyPath, not a file.". So again with the registry key paths.
2) I want the shortcut to be installed only if certain property is set
(from the checkbox). I can do that by creating a separate component with
just the shortcut in it, and add a condition to the component. However
it looks like I can't have a component with just a shortcut. The
Shortcut element has no KeyPath property and I get an error about the
missing KeyPath. So how do I create a component with just a single
shortcut inside?
Any ideas how to do what I need, and is it even possible?
Thanks
Ivo
----------------------------------------------------------------------------
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
