I want to make a wix installer, with an optional desktop shortcut for all users. Optional means, I cannot put it in the component of the main exe, but in a separate component, so that I can set a separate feature for the shortcut.
When doing this, wix complains:
error LGHT0204 : ICE38: Component DesktopShortcut installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file.
So I set an aditional registry key like this:
<Component Id="DesktopShortcut" Guid="767f3e19-9a7d-4793-9782-75516494a57c">
<Shortcut Target="[APPLICATIONROOTDIRECTORY]ocean.exe" Id="OceanShortcutDesktop" Name="$(var.ProductName)" WorkingDirectory='APPLICATIONROOTDIRECTORY' Icon="OceanIcon"/>
<RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]\installs' Name="desktopshortcut" Type='string' Value='' KeyPath='yes' />
</Component>
The shortcut goes in "All Users" since I set the ALLUSERS=1 property. However, there is no equivalent for registry, and the key goes in the current (installing) user registry. This is IMHO an issue : if the user profile gets deleted, the shortcut will not be deleted anymore on uninstall.
Using "HKLM" instead causes an error in wix (mixing per-user and per-machine):
error LGHT0204 : ICE38: Component DesktopShortcut installs to user profile. It's KeyPath registry key must fall under HKCU.
This is quite stupid from wix, as "All Users" component should be linked to the machine, and not to a normal user, as there is no "all users" registry.
Any idea?
You can try to change the registry root to 'HKMU' (From what I remember it's supposed to to write to the HKEY_LOCAL_MACHINE when the install is per-machine and under HKEY_CURRENT_USER when its not).
If you change the root to 'HKMU' you will get the ICE57 error (Component 'DesktopShortcut' has both per-user data and a keypath that can be either per-user or per-machine.)
You can suppress this error and the installer will create all-users shortcut
(It worked when I tried it, but I'm not sure it's the best way to do this).
(To disable the ICE57 error see: How to fix ICE57.Per-User installation)
Related
The Wix source code that I feed to the Wix compiler to build an MSI package for my application, contains the following PermissionEx directive, part of a file component which Windows Installer should install with additional (to those that should be inherited by default) permissions:
<PermissionEx Sddl="D:AR(A;;FW;;;BU)" />
As you can surmise, I intend to install the file with inherited permissions ("AR") included in its ACL and on top of that allow members of the Built-in Users group ("BU") to be allowed ("A") to write to the file ("FW").
The code above does not have the desired effect -- the file is installed, but only that single explicit ACE is listed, none of the ACEs that are supposed to be inherited from parent folder.
In contrast, if I subsequently remove all permissions from the file and run cacls file /S:D:AR(A;;FW;;;BU), i.e. specify exactly the same SDDL string, it does work as intended -- the permissions from parent are inherited and form part of the ACL, together with the explicit non-inherited ACE.
I am using Wix 3.11.1.2318 and the Windows Installer version is 5.0.16299.611, all running on Windows 10 Enterprise 64-bit. Orca tells me the MsiLockPermissionsEx table embedded in my built MSI file is populated with the intended SDDL record. So why is the file created without inheriting permissions from its containing folder?
I tried to use "AI" in place of "AR", and both strings together, but none of it had any effect either.
Is this some known limitation or a quirk with Windows Installer? I know that people were talking a while back how the old LockPermissions table (the one specified for Windows Installer versions earlier than 5) was inadequate in this specific regard -- inherited permissions, namely -- but they also said Microsoft was out to address this very issue with the new table feature.
Otherwise what am I doing wrong?
Given your knowledge in this field, you probably have already tried this. It would also be much better to eliminate the need for permissioning, but two snippets for you - notice the Append attribute:
Create a WiX project in Visual Studio. Add the Util namespace to the WiX element:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
In Visual Studio project, right click References and add reference to "%ProgramFiles(x86)%\WiX Toolset v3.11\bin\WixUtilExtension.dll".
Permission Folder:
<Component Feature="ProductFeature" Id="Test.exe" Guid="PUT-GUID-HERE">
<File Source="C:\Test.exe" />
<CreateFolder>
<util:PermissionEx User="Power Users" GenericWrite="yes" />
</CreateFolder>
</Component>
Permission File:
<Component>
<File Source="C:\Test2.exe">
<util:PermissionEx Append="yes" User="Users" GenericWrite="yes" />
</File>
</Component>
Take a look at WiX's custom PermissionEx in the Util extension.
http://wixtoolset.org/documentation/manual/v3/xsd/util/permissionex.html
I'm trying to solve my issue with autogerating GUID for multiple components in same folder installed under AppData (per-user installation).
Before edit I had one component with 3 files. Then I've decided to use auto GUID for this component, so I have divided it into 3 component (each with one file). I thought that now I can use Component GUID with * and registry value with KeyPath=yes but it's not working. Any advice is very appreciated.
Here is code snippet:
<Directory Id='INSTALLDIR' Name='$(var.myInstallDir)'>
<Component Id='MainExecutable' Guid='I_WOULD_LIKE_ASTERISK_HERE_ALSO_BUT_HAVE_HARD_CODED_GUID' >
<RemoveFolder Id='RemoveINSTALLDIR' Directory='INSTALLDIR' On='uninstall' />
<util:RemoveFolderEx On="uninstall" Property="APPLICATIONFOLDER" />
<RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]' Type='string' Name='Path' Value='[INSTALLDIR]' KeyPath='yes'/>
<File Id='ffile1' Name='file1' DiskId='1' Source='file1'> </File>
<Shortcut Id="startmenujfile" Directory="ProgramMenuDir" Name='$(var.myAppName)'
Target="[SystemFolder]cmd.exe" Arguments=" /c START javaw.exe -jar [INSTALLDIR]file1.jar ."
WorkingDirectory="INSTALLDIR"
Icon="apsoiconmultiico" IconIndex="0" />
<Shortcut Id="desktopjfile" Directory="DesktopFolder" Name='$(var.myAppName)'
Target="[INSTALLDIR]file1.jar" Arguments=" ."
WorkingDirectory="INSTALLDIR"
Icon="iconmultiico" IconIndex="0" />
</Component>
<Component Id='MainExecutable2' >
<File Id='ffile2' Name='file2' DiskId='1' Source='file2' />
<RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]' Type='string' Value='' KeyPath='yes'/>
</Component>
<Component Id='MainExecutable3' >
<File Id='ffile3' Name='file3' DiskId='1' Source='file3' />
<RegistryValue Root='HKCU' Key='Software\[Manufacturer]\[ProductName]' Type='string' Value='' KeyPath='yes'/>
</Component>
</Directory>
And error for components:
error CNDL0230 : The Component/#Guid attribute's value '*' is not valid for this component because it does not meet the criteria for having an automatically generated guid. Components with registry keypaths and files cannot use an automatically generated guid. Create multiple components, each with one file and/or one registry value keypath, to use automatically generated guids.
Thank you
EDIT:
Thanks to #Stein Åsmul answer. I need to ask one more time..
I'm trying to solve this because we are moving from Java Web Start (jnlp) to very simple .msi file which installs only elementary files and shortcuts. Then the app itself has automatical update system which downloads all other files.
Our app can have "mupliple sets of versions" installed on same machine (like set A: "app 1 demo, app 2 test" and set B: "app 2 demo, app 2 test"). Every set and every version in the set can have different files (this is a job for update system itself).
Now the question. I'm a newbie in .msi installation so I'm not sure about many steps. I know productId, upgradecode.. but what about component GUID (in my case Component Id='MainExecutable') in enviroment with multiple sets of app installed on same machine (per-user but different directory - AppData/local/setA and AppData/local/setB) with registry KeyPath=yes? Can this component has fixed GUID for all our installations if productId is different (so hardcoded in .wxs for all installations)? Thank you for explanation.
Short Answer: You cannot use auto-guids for components that have the same / non-unique key path - which is the case for per-user registry key paths. Simpler approach: Install files to a per-machine location and copy them into each user-profile on application launch instead of
installing them per-user via an MSI. This de-couples all user-profile files
from common deployment problems (overwriting / resetting, upgrade problems, uninstall problems, etc...). Auto-Guids are possible for per-machine key paths - they are unique per component.
Per-User Key Path: HKCU\Software\Company\Product\MyKeyPath
Repeats for every user! => No auto-guid possible. It is not unique.
User 1: C:\Profiles\User1\Product\File.exe, Key path: HKCU\Software\Product\MyKeyPath
User 2: C:\Profiles\User2\Product\File.exe, Key path: HKCU\Software\Product\MyKeyPath
For the record, here is what would happen if you set a userprofile disk-based key-path (as opposed to a registry key path which you are supposed to use): Color illustration.
Per-Machine Key Path: C:\Program Files\Company\Product\Main.exe
Only one installation instance! Unique key path allows auto-guid.
Read-Only Templates: A general issue first: it is recommended that you don't install files directly into the user profile folders. Rather you should install them to your main installation folder under Program Files and then copy them in place during application launch for every user who uses the application. The files can then be copied to every user-profile on demand and on launch of the application (upgrades are possible too, if you implement it well).
Technically: You cannot use an auto-guid for components that has the same / non-unique key path. The technical reasons can perhaps be best understood by reading this old answer: Change my component GUID in wix? Essentially the key path must be unique in order to be able to create an automatic GUID, and this is not the case with per-user registry keys. The path is the same for all users - to the same registry key (even if the content is different for each user). A limitation of the MSI technology.
Note that if you install to a per-machine path you will be able to use auto-GUIDs since you can have a unique file key path for the component. This should work fine. Just move the files to a per-machine path and set an auto-guid. Upgraded files will overwrite older files and you can copy newer files over the ones in the user profile on launch - if desirable. A risky operation most of the time.
Cloud: I am fond of cloud-based approaches to download files into the user profile on-demand directly from the Internet or Intranet as an alternative to deployment via MSI. It all depends what you have access to.
More Details: There are too many pre-existing answers that revolve around the same points for there to be any value in rewriting it. Please check the below links for more details on the deployment of per-user files with MSI:
Create folder and file on Current user profile, from Admin Profile
Wix deferred custom action access denied
How to create nested folder in AppData
Create a .config folder in the user folder
Make WIX installer place files in AppData
I have a WIX installer set up for my application and it installs correctly and updates correctly except that it re-writes the default user settings (i.e. defined in properties-> settings) that are defined in my application and corresponding dll's. How can I have WIX update the application, but not update the user settings?
Whether it's ini, registry or xml the concept is simple. Only have the installer responsible for installing defaults settings. Then on first run on your application copy the default settings to the user settings one time. Now the installer will never harm user settings because it doesn't even know of their existence.
Properties -> Settings are mapped to the app.config file for your application, so you can setup the install for that particular file to NeverOverwrite, meaning updates will not overwrite your .config file.
Working example:
<Component Id="SPECTRAVIEW.WPF.MAINAPPLICATION.EXE.CONFIG" Win64="$(var.Win64)" Guid="89E2C6C0-18FB-428B-A9EE-C2FAB3418CB2" NeverOverwrite="yes">
<File Id="SPECTRAVIEW.WPF.MAINAPPLICATION.EXE.CONFIG" Name="SpectraView.WPF.MainApplication.exe.config" Source="$(var.MainApplication.TargetDir)\SpectraView.WPF.MainApplication.exe.config" KeyPath="yes" />
</Component>
I added a registry key value into the registry on install.And I want to modify that registry key value on uninstall but I don't want to removing that from registry.
1)I tried with custom actions execution on uninstall to modify the registry value. But the registry values are removing from the registry on uninstall.
2)If I make the component to permenent then it is not modifying the key value at the time of uninstall.
<Component Id="SampleRegComp"
Guid="3865FE52-F8EE-4E29-B321-BDF0FD6D3F58"
Permanent="yes">
<RegistryKey Action="create"
Key="SOFTWARE\Microsoft\Notepad"
Root="HKCU">
<RegistryValue Name="StatusBar" Type="integer" Value="1" />
</RegistryKey>
</Component>
<CustomAction
Id="ModifyOutlookRegInitSign_12"
Return="ignore"
Directory="TARGETDIR"
ExeCommand= ""[SystemFolder]reg.exe" ADD "HKCU\SOFTWARE\Microsoft\Notepad" /v StatusBar /t integer /d 0 /f" >
</CustomAction>
Installed
The short answer is to create the registry entry with your code and modify it with your code, then it's clear that you are managing those entries, not both you and the MSI setup.
An alternative is to put them in a component by itself with a null component guid, then MSI won't manage it at all after it's been installed.
Phil has already answered, but maybe I can add that you can use (REMOVE="ALL" AND NOT UPGRADINGPRODUCTCODE) for the custom action to be executed during uninstallation. Then just set the registry component permanent (HKCU registry data shouldn't really be uninstalled either - a matter of some debate though). This still won't fix the HKCU data for users who are not logged on at the time of the uninstall though. This is a much more involved task, probably possible to do with ActiveSetup.
Adding NOT UPGRADINGPRODUCTCODE ensures uninstalls performed as part of major upgrades do not update the registry since the product is then due to be reinstalled. Shouldn't be necessary for your case, but ensures the custom action doesn't run unnecessarily.
I would suggest scheduling the custom action right before InstallFinalize in the InstallExecuteSequence. I haven't tested this location, but it is then one of the last actions to run during the uninstall, and should have the desired effect.
See the condition lists for detecting different installation modes at the bottom of this thread.
Our application writes some settings to the registry into the HKCU hive during runtime. I want to delete this settings during uninstall. Here is code:
<Fragment>
<DirectoryRef Id="INSTALLLOCATION" DiskId="1" FileSource="$(var.SourceDirProject)\">
<Component Id="DeleteHkcuManufacturerHive" Guid="GUID">
<Condition>REMOVE="ALL" AND NOT UPGRADINGPRODUCTCODE</Condition>
<CreateFolder/>
<RemoveRegistryKey Action="removeOnUninstall"
Id="HKCUkey" Root="HKCU" Key="Software\$(var.Manufacturer)"/>
</Component>
</DirectoryRef>
</Fragment>
ICE57: Component 'DeleteHkcuManufacturerHive' has both per-user and per-machine data with a per-machine KeyPath.
Why I'm getting ICE57? Installation is per-User. Thank's in advance.
UPD: Where is here the per-machine element? May be it is an INSTALLLOCATION=Program Files\ManufacturerDirectory?
You are operating on the HKCU hive which is only available to the current user.
MSDN states:
ICE57 validates that individual components do not mix per-machine and
per-user data. This ICE custom action checks registry entries, files,
directory key paths, and non-advertised shortcuts. Mixing per-user and
per-machine data in the same component could result in only partial
installation of the component for some users in a multi-user
environment.
The ICEs are validations on your installation package. As stated above, ICE57 is to make sure you don't mix up per-machine and per-user constructs. If you must remove entries to HKCU during uninstall (and the software is installed per-machine) then you can turn off that specific validation in Visual Studio in Properties > Tool Settings as shown in the screenshot below:
However, you may want to think about the root cause of your issue. If you are doing a per-machine install, your installer or application should probably not be writing to HKCU as it is only available to the current user, whereas your app is installed for all users.
I've got an answer on wix-users mailing list. Here is Peter Shirtcliffe's answer:
ProgramFiles is a per-machine location. You can only access it when elevated. If you want to install program code in a per-user installation, you should install to %LocalAppData%\Programs.
Remove the condition entirely. The component will be installed but will have no effect until you uninstall the application. At that point, when the component is removed, the registrykey will be removed also.