Following directory setting works perfectly for me.
<Directory Id='TARGETDIR' Name='SourceDir'>
<Directory Id="ProgramFilesFolder">
<Directory Id='INSTALLDIR' Name='MyApp'/>
</Directory>
</Directory>
However, when I tried changing "ProgramFilesFolder" to "LocalAppDataFolder", I got lots of error when using light to link and generate my msi:
D:\runGroup.wxs(53) : error LGHT0204: ICE38: Component cmpA5561BE36D80EB58252E69DDA0C2FF8C installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file.
D:\main.wxs(38) : error LGHT0204 : ICE64: The directory INSTALLDIR is in the user profile but is not listed in the Remove File table.
Looks like "LocalAppDataFolder" is not acceptable for WiX, while I believe it is one of the system folder properties which defined in here.
What am I supposed to use for LocalAppData folder?
I converted an application from being a perMachine install to be a perUser install. In order to properly convert the install I had to add a registry key for each of the components I have.
Originally I had the following:
<Component Id="C.MyExe">
<File Id="Fi.MyExe" Name="$(var.MyExe.TargetFileName)" Source="$(var.MyExe.TargetPath)" DiskId="1">
<Shortcut Id="SC.StartMenu"
Directory="D.ApplicationMenuDir"
Name="$(var.AppName)"
WorkingDirectory="INSTALLDIR"
Icon="MY_ICON.ico"
IconIndex="0"
Advertise="yes"
/>
...
When I moved the exe component to the user install I had to do something like this:
<Directory Id="LocalAppDataFolder" Name="AppData">
<Directory Id="MyAppDirectory" Name="$(var.AppName)">
<Component Id="C.MyExe" Guid="{MY_GUID}">
<CreateFolder />
<RemoveFolder Id="RemoveMyAppDirectory" On="uninstall" />
<RegistryKey Root="HKCU" Key="Software\MyCompany\MyApp">
<RegistryValue Name="MainExe" Value="1" KeyPath="yes" Type="integer" />
</RegistryKey>
<File Id="Fi.MyExe" Name="$(var.MyExe.TargetFileName)"
Source="$(var.MyExe.TargetPath)" DiskId="1" Checksum="yes">
</File>
</Component>
...
The most important part is that you will have to add a registry key which points to HKEY_CURRENT_USER. I added a registry value for each component which indicates that the component is installed.
I also had to remove the following: Advertise="yes".
I had this problem recently. I wanted to convert my installer from per-machine to a per-user but was getting ICE38. I asked on wix-users and one opinion was that you can ignore ICE38 because that was meant as a check for per-machine installs.
See the discussion at wix-users.
Since that is the case, ICE38 is (in my opinion) incorrect and you will want to ignore it. ICE38 implies you are installing per-user resources in the context of a per-machine installation but never verifies that this is so.
Actually authoring a per-user install requires that you ignore ICE38
because it won't ever be accurate for that world.
[Edit]
Looks like you got help here.
From Peter Shirtcliffe:
This is my own, admittedly inexpert, understanding of per-user installations:
Installing to subdirectory of LocalAppDataFolder is perfectly OK in a
per-user MSI. Because of certain scenarios relating to roaming users, you
need to add components containing elements for any
directories you create under LocalAppDataFolder. That's why ICE64 is
appearing.
The ICE38 error is slightly misleading: since you have a per-user
installation, it's safe to ignore as long as the user cannot pick an
alternative installation location that is common to all users. ICE38 is
checking for the situation where multiple users all install the same
component to the same path.
Just posting to help other people (like me).
Ok, just found that we can do it by overwriting "ProgramFilesFolder":
<SetProperty Id="ProgramFilesFolder" Value="[LocalAppDataFolder]" Before="CostFinalize"><![CDATA[NOT Privileged]]></SetProperty>
Another thing to do is, in <Package> we need to set InstallPrivileges to limited.
Well, I can see no reason why "ProgramFilesFolder" can be used directly while "LocalAppDataFolder" can't.
Are you installing per-user or per-machine? Also, what OS versions are you targetting? You might want to read:
Authoring a single package for Per-User or Per-Machine Installation context in Windows 7
Related
Brand new to WiX and I'm trying to fix a bug in some software I took over recently. As part of the product definition we have certain files being installed to the user's "AppData\Local" directory. The current project setup works fine when the user has install privileges, with the files being placed in the expected users "AppData\Local" directory.
However, if the UAC prompt pops up requiring admin credentials, the files end up being install in the admin account's "AppData\Local" directory instead.
In the product file we have something like:
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="LocalAppDataFolder">
<Directory Id="MyData" Name="My Data">
...
</Directory>
</Directory>
</Directory>
And then in a heat.exe generated file I have
<Fragment>
<DirectoryRef Id="MyData">
<Directory Id="UserMaps" Name="User Maps" />
</DirectoryRef>
</Fragment>
<Fragment>
<ComponentGroup Id="User_Maps_Components">
<Component Id="Map1.png" Directory="UserMaps" Guid="{C27...autogenerated}">
<File Id="Map1.png" Source="$(var.MapPath)\Map1.png" KeyPath="no" />
<RegistryValue KeyPath="yes" Root="HKCU" Key="Software\MyApp\Usermaps" Type="integer" Value="1" Name="Map1.png" />
</Component>
</ComponentGroup>
</Fragment>
Is there a way to ensure that the files will be installed to the initiating user's directories, rather than the admin's account?
We have files installing to "Program Files" as well, so I could always install the files there and copy them over as part of my applications initialization logic if they aren't found in the active user's folders, but was interested in seeing if there was a WiX specific way of doing things.
I assume you are actually entering an admin password and specifying an admin account to run the setup with? That is as opposed to elevating the admin account you are logged in with. The latter should make the file install in the expected folder. The former would install like you describe.
I would roll with the approach you describe yourself: copy the file in place to each user profile from a copy installed per machine. I wrote up some suggestions for user profile and HKCU deployment a while back. Just some thoughts on the subject - a subject which seems to have few good answers. The Active Setup approach is apparently no longer supported in Windows 10.
Throwing in Some Links:
Why is it a good idea to limit deployment of files to the user-profile or HKCU when using MSI?
Create a .config folder in the user folder
C++ MSI Package Administative Privileges
System.UnauthorizedAccessException while running .exe under program files
Why WIX does not remove a shortcut in the INSTALLDIR if it is not the default install directory is used? My WIX code look like?
<DirectoryRef Id="INSTALLDIR">
<Component Guid="..." Id="shortcuts_INSTALLDIR">
<RegistryKey ForceDeleteOnUninstall="yes" Id="shortcuts_reg_INSTALLDIR" Key="Software\MyCompany\MyProduct" Root="HKCU">
<RegistryValue KeyPath="yes" Name="shortcut_INSTALLDIR" Type="string" Value=""/>
</RegistryKey>
<Shortcut Arguments="my args " Description="my description" Id="InstallDir_my_name" Name="my name" Target="[INSTALLDIR]mydir\my.exe" WorkingDirectory="INSTALLDIR"/>
</Component>
</DirectoryRef>
It look like that the uninstaller does not know the new value of INSTALLDIR. Any idea?
Windows Installer is a bit of an odd beast here. It doesn't record the operations it performs; instead it tries to record the information necessary to reverse them. In this case it appears you're falling into a gap in that implementation.
Windows Installer notes that it has installed component shortcuts_INSTALLDIR. When a file is installed to a specific directory, it records the directory's location. Then during maintenance it restores all the directories it recorded. But it does not record (and thus does not restore) the directory for just a shortcut. Typically shortcuts are installed to predefined paths under the ProgramMenuFolder. Since such locations are not affected by changes to INSTALLDIR, this is usually not a problem.
To solve this you have to ensure the alternate INSTALLDIR is restored during maintenance. You can convince Windows Installer to do so automatically by installing any file directly to INSTALLDIR (if the extra file is not a problem, this is my preferred option). Alternately you can do so manually through the remember property pattern, possibly leveraging ARPINSTALLLOCATION and its saved value in the Uninstall key.
I am struggling against the issue with wix toolset: why after I uninstall an application some folders including the "logs" are not deleted? is it a bug or not?
<Directory Id="logs" Name="logs">
<Component Id="logs" Guid="0A4D0A3F-2E0D-1B1A-1C6D-1A0F8FAAABC6" Win64="$(var.is64)">
<CreateFolder Directory="logs">
<Permission GenericAll="yes" User="Everyone" />
</CreateFolder>
<RemoveFolder Id="logs" On="uninstall"></RemoveFolder>
</Component>
</Directory>
Sometimes if the application you install generates files or folders after the installation, that can prevent WiX from removing the parent folder during uninstall.
If there are log files created after install, you can purge them by adding this to your existing component:
<RemoveFile Id="RemoveLogFiles" Name="*.*" On="uninstall" />
If your application also creates subdirectories and RemoveFile doesn't get rid of them, I would look into using RemoveFolderEx(http://wixtoolset.org/documentation/manual/v3/xsd/util/removefolderex.html). This would require you to to create a Property and write the directory path to a place in the registry so you can set the Property before RemoveFolderEx runs. You can't just use the Directory Id because RemoveFileEx runs before the MSI creates the Directory properties. Read the link I provided if my explanation didn't make sense to you.
Hope this helps!
I have a permachine MSI installer that I'm converting to a per user installer that is installing files to the LocalAppDataFolder.
To get rid of ICE38 warnings I added a registry as the keypath. The problem is in one of my components I have a advertised shortcut and ProgId.
I'm now getting:
ICE19 - 'settings' advertises component: 'CMP_Rapid'. This component cannot be advertised because the KeyPath type disallows it
ICE19 - Shortcut: 'SHC_RunConfigExe' advertises component: 'CMP_Rapid'. This component cannot be advertised because the KeyPath type disallows it.
ICE50 - Component 'CMP_Rapid' has an advertised shortcut, but the KeyPath cannot be found.
Is there anyway to advertise in per user installs when installing to the LocalAppDataFolder? I'm not that familiar with advertising. On the shortcut I use it because I like the repair functionality it offers. On the progId I use it because it automatically updates the appropriate icons after an install.
I need to install this on XP and Vista so I can use the Windows 7 solution: ProgramFilesFolder redirection.
Below is the component that generates the errors:
<DirectoryRef Id="INSTALL_FOLDER">
<Component Id="CMP_Rapid"
Guid="{9373A11C-5A3C-49E3-963D-C19B765A4285}">
<File Id="FILE_Rapid"
Source="$(var.FilePath)\Dynagen Configurator.exe">
</File>
<Shortcut Id="SHC_RunConfigExe"
Name="DYNAGEN Configurator"
Description="Opens DYNAGEN Configurator application."
Directory="ConfigShortCutDir"
WorkingDirectory="INSTALL_FOLDER"
Icon="ICO_RunConfigExe.exe"
Advertise="yes"/>
<ProgId Id="Rapid.drcS" Icon="ICO_drcS.ico" Advertise="yes">
<Extension Id="settings">
<Verb Id="Open" Command="Open" Argument="/so "%1"" />
<Verb Id="Edit" Command="Edit" Argument="/edit "%1""/>
<Verb Id="Program" Command="Program" Argument="/program "%1""/>
</Extension>
</ProgId>
<RegistryValue Root="HKCU"
Key="Software\Dynagen\DynagenConfigurator"
Name="CMP_Rapid"
Type="integer"
Value="1"
KeyPath="yes"
/>
</Component>
</DirectoryRef>
Turns out satisfying ICE38 by making a registry key the keypath is wrong. The proper thing to do is to ignore the ICE38 error but going going into the wix properties page and add ICE38 and ICE91 beside "Suppress specific ICE validation.
Microsoft or Wix doesn't have ideal support for pure per-user installs. I couldn't even find any good examples online.
Bryan at WiX-users#lists.sourceforge.net helped me out on this:
Since that is the case, ICE38 is (in my opinion) incorrect and you will want to ignore it. ICE38 implies you are installing per-user resources in the context of a per-machine installation but never verifies that this is so.
Actually authoring a per-user install requires that you ignore ICE38 because it won't ever be accurate for that world.
Once I ignored that the above worked.
[Edit]
See my answer here as well. Turns out there is some edge cases you need to be aware of.
I have a similar problem like forki23 by bring Wix to not overwrite a configuration file during upgrade. I have a config file that should not be overwritten during upgrade, but it should be removed during uninstall. However every solution I find, breaks something else.
If I set NoOverwrite=yes and move the RemoveExistingProducts to InstallFinalize the config file is handled as I wished. However, in this case the shortcut is removed during upgrade for some reason. If I leave RemoveExistingProducts at InstallInitialize, the config file is actually removed during upgrade, however the shortcuts are present.
Why is this happening and is there are way to fix it?
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallInitialize" />
<!-- InstallInitialize causes config-file to disappear during upgrade -->
<!-- InstallFinalize causes shortcuts to disappear during upgrade -->
...
<Property Id="DISABLEADVTSHORTCUTS" Value="1" />
...
<Directory Id="INSTALLLOCATION" Name="MyApp">
<Component Id="MYAPP.EXE" DiskId="1" Guid="...">
<File Id="MYAPP.EXE" Name="MyApp.exe" Source="..." Vital="yes" KeyPath="yes">
<Shortcut Id="startmenuShortcut"
Directory="ProgramMenuDir"
Name="!(loc.ProductName)"
WorkingDirectory='INSTALLLOCATION'
Icon="Icon.ico"
IconIndex="0"
Advertise="yes" />
</File>
<RegistryValue Root="HKLM"
Name="InstallLocation"
Key="$(var.InstallLocationRegistryKey)"
Type="string"
Value="[INSTALLLOCATION]">
</RegistryValue>
</Component>
<Component Id="MYAPP.EXE.CONFIG" DiskId="1" Guid="..." NeverOverwrite="yes">
<File Id="MYAPP.EXE.CONFIG"
Name="MyApp.exe.config"
Source="..."
KeyPath="yes" />
</Component>
...
</Directory>
...
<Directory Id="ProgramMenuFolder">
<Directory Id="ProgramMenuDir" Name="!(loc.ProductPrefix)">
<Component Id="ProgramMenuDir" Guid="...">
<RegistryValue Root="HKCU" Key="SOFTWARE\MyApp"
Type="string" Value="[INSTALLLOCATION]" KeyPath="yes" />
<RemoveFolder Id="ProgramMenuDir" On="uninstall"/>
</Component>
</Directory>
</Directory>
Note A: The config-file is a machine-wide configuration and should apply for all users.
Note B: I'm using WiX 3.7 and the target plattform is Windows 7 and 8.
Theoretically "NoOverwrite=yes and move the RemoveExistingProducts to InstallFinalize" should work, but it s clear we are losing something from the big picture. The best method to see why Windows Installer removes the shortcuts is to create a verbose log when launching the upgrade setup. You can do that in a cmd.exe with this command: msiexec /i [msi path] /L*V debug.log
The post the a download link for the log and the GUIDs of the components hosting the shortcuts so we can see if the log helps us understand what happens.
Windows installer works very exact in those things, and if anything gets removed in the After="InstallFinalize" case, this means, that a component has been removed, MSI has thought is not needed, because not contained in your new version of the msi file. Be very sure the GUID of the component containing MYAPP.exe and the shortcut has not changed in your new version. (Compare with a tool like Orce or Insted). It seems it has!
MSI removes only full components, not only shortcuts. Really! Maybe you have an update problem of shortcuts in Windows. Sometimes such things happen. Try to reboot to be sure, that this happens, what you think. Maybe there is an error in your test procedure (or it's the above mentioned GUID problem). There are not many other possibilities, if you have not custom actions which remove shortcuts or you try to add shortcuts as files or such dangerous stuff.
Putting a shortcut in the same component as the .exe is common, but not optimal in my eyes! I recommend to separate resources as much as possible, so put it in an own component. This has advantages, if you later want to rename the shortcut. Then you can just change the GUID of this component and the important .exe file is not touched.
There is a small disadvantage of that, loosing the direct connection to the file version of MYAPP.exe in overinstall scenarios, so if MYAPP.exe is a shared file between several different setups, this is not recommended. Perfect solutions for this are possible, but are not in the focus here.
Workaround: If you are still able to change the old (first) msi setup, just mark the component MYAPP.EXE.CONFIG as permanent. Then it will not be uninstalled during Major Upgrade (but not uninstalled at all, what has advantages and disadvantages, in other words, it is mostly acceptable for .config files).
If version 1 of your setup is already shipped, then you could do the same with some tricks too.