I'm using wix IniFile element to edit ini file on install. When I try to uninstall i get error 2343:
Начало действия 12:37:47: RemoveIniValues.
MSI (s) (7C:BC) [12:37:47:264]: Note: 1: 2343
DEBUG: Error 2343: Specified path is empty.
My wxs with ini editing is as follows:
<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<Property Id="miktex_config_path" Hidden="yes"/>
<SetProperty Id="miktex_config_path" Value="[INSTALLLOCATION]miktex\miktex\config" After="InstallFiles" Sequence="execute">Not Installed</SetProperty>
<DirectoryRef Id="dirC060208F28327102C690BFF33C18B6C4">
<Component Id="miktex_config_file" Guid="4B9400C2-7EEF-4233-881D-5DFE6F80BB5B">
<CreateFolder />
<IniFile Directory="miktex_config_path" Id="common_install_path" Name="miktexstartup.ini" Action="addLine" Key="CommonInstall" Value="[INSTALLLOCATION]miktex" Section="Paths"/>
<IniFile Directory="miktex_config_path" Id="common_data_path" Name="miktexstartup.ini" Action="addLine" Key="CommonData" Value="[CommonAppDataFolder]miktex_data" Section="Paths"/>
<Condition><![CDATA[Not Installed]]></Condition>
</Component>
</DirectoryRef>
</Fragment>
</Wix>
Why doesn't uninstaller take into account my condition element?
How can I force installer to ignore ini file editing during uninstall?
The condition is against the component, however the action that is running is RemoveIniValue. You can surpress this action by overriding InstallExecuteSequence as follows:
<InstallExecuteSequence>
<RemoveIniValues Suppress="yes" />
</InstallExecuteSequence>
It depends on the task you pursue. If you need to prevent INI value removal at all then suppressing the RemoveIniValues in the InstallExecuteSequence is the way to go as suggested by David Martin. However, that suppression (NO MATTER what you put as a condition for that), prevents the INI entry removals and for install and for uninstall (again, condition doesn't work, don't even try to put condition to suppress on uninstall only). But if you need to allow INI entry/tag removals during the install (IniFile declaration with remove action) but at the same time you need to prevent the rest of your INI settings from removal during the uninstall, then simply mark the Component where you keep your IniFile declarations as Permanent="yes". In that case your INI settings will not be removed on uninstall and your declarations to remove particular INI settings on install will work, And forget about the RemoveIniValues suppression at all.
Related
I am really new using WIX, my only experience to build a complete install was with INNO, and WIX has been decided the way to go for an MSI
The installation includes a bunch of examples and templates, 427 files, which seems crazy to enumerate even with an utility like HEAT.EXE
So we went for a self-extracting utility. WIX install includes this custom utility and the compressed cabinet file, and then that extracts files and folders via custom action.
Problem is when we try to delete the compressed file and the extractor utility. I haven't found the way to delete them after the extraction takes place. RemoveFile seems to not work, and deleting the file within the extraction utility fires the self-healing mechanism in every run of the application.
Leaving the files in the install is dangerous, it is 200MB and it would reset all the installed examples if user runs the self-extraction utility by accident.
If it is of use, the WIX snippet in charge of this is like that:
<Fragment>
<ComponentGroup Id="App_Files">
<Component Id="cmp_Files_Dat" Directory="INSTALLCOMMONFOLDER" Guid="{8BFED6C2-4D4F-48BB-xxxx-C171F624C90B}">
<File Id="fil_Files_Dat" Source="appfiles\files.dat" />
<RemoveFile Id="rem_Files_Dat" Name="files.dat" On="install" />
</Component>
<Component Id="cmp_UnpackFiles_exe" Directory="INSTALLCOMMONFOLDER" Guid="{5722B5E0-C6E8-4C71-yyyy-61EC0ACA0D72}">
<File Id="fil_UnpackFiles_exe" Source="appfiles\UnPackFiles.exe" Checksum="yes" />
<RemoveFile Id="rem_UnpackFiles_exe" Name="UnPackFiles.exe" On="install" />
</Component>
</ComponentGroup>
<CustomAction Id="action_UnPackFiles" FileKey="fil_UnpackFiles_exe" ExeCommand="[INSTALLCOMMONFOLDER]" Execute="commit" Return="check" Impersonate="no" />
<InstallExecuteSequence>
<Custom Action="action_UnPackFiles" After="InstallFiles" > NOT (REMOVE="ALL") </Custom>
</InstallExecuteSequence>
</Fragment>
The net result of the code above leaves the files, does not remove them.
Thanks in advance
Josep
I have been working on a WIX installer for an application and am stuck on a small part of the upgrade: there are two XML configuration files in the install directory that I would like to copy to the new ProgramData directory (since they will not be in ...\Program Files... going forward).
I have tried several solutions, including different brackets/apostrophes/", to no avail. When I compile the WIX installer, I receive several warnings from CANDLE about the Property containing [CommonAppDataProduct] and [PRODUCTNAMEFOLDER], but I am unsure if there needs to be some reference / PropertyRef from those directories defined in the Product.wxs to each custom action.
Snippets of Product.wxs:
<Product Id="*" Name="$(var.ProductName)" Language="0" Version="$(var.Version)" Manufacturer="$(var.Manufacturer)" UpgradeCode="$(var.UpgradeCode)">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<InstallExecuteSequence>
<SelfUnregModules/>
<SelfRegModules/>
<Custom Action="CopyConfigFilesToTemp" After="InstallValidate" />
<Custom Action="LaunchDPInstActionx86" Before="InstallFinalize">NOT Installed OR MaintenanceMode="Modify"</Custom>
<Custom Action="CopyConfigFilesFromTemp" After="LaunchDPInstActionx86" />
</InstallExecuteSequence>
</Product>
...
<Fragment>
<Directory Id="$(var.PlatformProgramFilesFolder)">
<Directory Id="PRODUCTNAMEFOLDER" Name="$(var.ProductName)"/>
</Directory>
</Fragment>
Custom action CopyConfigFilesToTemp
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<Property Id="QuietExec2" Value='"xcopy.exe [PRODUCTNAMEFOLDER]*.xml" %TEMP% /I /Y'/>
<CustomAction Id="CopyConfigFilesToTemp" BinaryKey="WixCA" DllEntry="WixQuietExec" Execute="immediate" Return="ignore"/>
</Fragment>
</Wix>
Custom action CopyConfigFilesFromTemp
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<Property Id="QuietExec3" Value='"xcopy.exe %TEMP%\*.xml [CommonAppDataProduct]" /I /Y /R'/>
<CustomAction Id="CopyConfigFilesFromTemp" BinaryKey="WixCA" DllEntry="WixQuietExec" Execute="immediate" Return="ignore"/>
</Fragment>
</Wix>
These custom actions must be deferred custom actions because they are trying to modify something in the program files path which requires elevated privileges. The only portion of the install that has elevated privileges is the server server portion of the install when it is copying over files to the install directory.
Custom actions that are deferred have a special requirement on them if you intend to use one of the msi properties within the action.
As per microsoft's website on Deferred Actions
Because the installation script can be executed outside of the installation session in which it was written, the session may no longer exist during execution of the installation script. This means that the original session handle and property data set during the installation sequence is not available to a deferred execution custom action.
This essentially means that you need to put the values of your properties in a special location that is guaranteed to exist while the elevated portion of the install is happening and must be formatted in such a way that it knows exactly where to look to get that value.
So to run these actions they must be scheduled between InstallInitialize and InstallFinalize and must also be able to grab the property values from a special location.
To use a deferred custom action you just need to change the execution to deferred however, we must add this special property with a formatted value so that you can get the values of QuietExec and QuietExec2 from within your custom actions.
You need to declare a custom action as follows for each of the deferred actions:
<CustomAction Id="CustomActionNameHere" Property="CopyConfigFilesToTemp" Value="QuietExec2="xcopy.exe [PRODUCTNAMEFOLDER]*.xml" %TEMP% /I /Y" />
<CustomAction Id="CustomActionNameHere" Property="CopyConfigFilesFromTemp" Value="QuietExec3="xcopy.exe %TEMP%\*.xml [CommonAppDataProduct]" /I /Y /R" />
Generally I call these the same name as the custom action they're setting a property for with "Set" prefixed to the name. IE: SetCopyConfigFilesFromTemp and SetCopyConfigFilesToTemp so that they are easy to locate.
You also must schedule these custom actions and you can't go wrong scheduling them before the action they set properties for and match the conditions.
<Custom Action="SetCopyConfigFilesToTemp" Before="CopyConfigFilesToTemp">
<Custom Action="SetCopyConfigFilesFromTemp" Before="CopyConfigFilesFromTemp">
In the custom action code, you need to use session.CustomActionData["PropertyName"] instead of just session["PropertyName"]
I would also consider the situations when you want to run these copy commands since I don't think you want to do them when uninstalling the product or if its a fresh install and not an upgrade.
I am wanting to install files during a wix install conditionally whether a command line parameter has been set
e.g. I have the following file, which only installs if a DEBUG flag has been set
<Component Id="file.pdb" Guid="SOME-GUID">
<Condition>DEBUG</Condition>
<File Id="file.pdb" Source="file.pdb" KeyPath="yes" Vital="no" />
</Component>
I have added the DEBUG property and read it in from the command line. The File never installs though, I am perplexed as to why?
Solved the issue. Below is an explanation of what I was doing wrong and what I did to solve it
I had created an installer (.msi) and was using the following cmd line args to start it up
msiexec -i prog.msi DEBUGPROPERTY=True
I had several merge modules with components which would install depending on whether this property was set which were getting the property injected into them like so...
<Merge
Id="SomeID"
Language="1033"
SourceFile="Module.msm"
DiskId="1">
<ConfigurationData
Name="debugProperty"
Value="[DEBUGPROPERTY]" />
What I was missing was in the merge modules (.msm) i needed the following code
<Configuration Name='debugProperty' Format='Text' DefaultValue='[DEBUGPROPERTY]'/>
<Substitution Table='CustomAction' Row='setDebugProperty' Column='Target' Value='[=debugProperty]'/>
<CustomAction Id='setDebugProperty' Property='DEBUGPROPERTY' Value='[DEBUGPROPERTY]'/>
<InstallExecuteSequence>
<Custom Action='setDebugProperty' Before="LaunchConditions">1</Custom>
</InstallExecuteSequence>
This allowed me to access the property DEBUGPROPERTY inside this module so i could restrict whether a file was installed at install time or not, like so
<Component Id="File.pdb" Guid="SOME-GUID">
<Condition>DEBUGPROPERTY</Condition>
<File Id="File.pdb" Source="File.pdb" KeyPath="yes" Vital="no" />
</Component>
This now works, and allows me to install .pdb files during an install if i include this argument.
I'm wondering if it's possible to manually run a RemoveFolderEx element from a custom action. I'm guessing probably not but someone may know a way that I'm not aware of.
My problem is I want to run the RemoveFolderEx element but only on an true UNINSTALL however my program executes it when upgrading as I've set it to uninstall before reinstalling.
I tried it via this method
Wix: condition on property not working
however it didn't work and still ran when doing a reinstall.
The only thing I can think of is being able to manually set a RemoveFolderEx off from a custom action which I know that I run at the correct point and only on a true uninstall. Perhaps my custom action could use a c++ dll and then manually add the command to the MSI interface but if I'm going that far it might just be as well to fully write the deletion logic myself.
Thanks. Neil
EDIT: I finally got this working, here is some example wix to show what I did.
<Property Id='P.REMOVEDATAFOLDER' Secure='yes' />
<DirectoryRef Id="DATADIR">
<Component Id="C.RemoveDataFolder" Guid="myguid" KeyPath="yes">
<util:RemoveFolderEx On="uninstall" Property="P.REMOVEDATAFOLDER" />
</Component>
</DirectoryRef>
<CustomAction Id="CA.SetDataFolder" Property="P.REMOVEDATAFOLDER" Value='[DATADIR]' />
<InstallExecuteSequence>
<Custom Action="CA.SetDataFolder" Before="ValidateProductID" >(NOT UPGRADINGPRODUCTCODE) AND (REMOVE="ALL")</Custom>
</InstallExecuteSequence>
The property P.REMOVEDATAFOLDER only gets set on a true uninstall immediately after DATADIR is read from the registry but before the CostInitialize action.
I would use the following approach. Do not condition RemoveFolderEx operation, but use a conditioned custom action to set the appropriate value for the target property.
Taking some advice from this question, the condition that denotes uninstall is REMOVE="All" AND NOT UPGRADINGPRODUCTCODE.
Something like this may work:
<Component Id="RemoveMyFolder">
<Condition> REMOVE="All" AND NOT UPGRADINGPRODUCTCODE </Condition>
<RemoveFolderEx ... />
</Component>
My application has a settings file which I need to keep when user uninstalls the app. Can I do this using components, or do I need to use custom actions?
This is what I have so far (not working):
<Directory Id="INSTALLLOCATION" Name="_MyApp">
<Component>
<File KeyPath="yes" Source="$(var.Source)\settings.ini" />
</Component>
<Component Id="Backup" Guid="SOME-GUID">
<Condition>REMOVE=ALL</Condition>
<CopyFile Id="settings.ini" Delete="no" SourceProperty="INSTALLLOCATION" DestinationProperty="INSTALLLOCATION" SourceName="settings.ini" DestinationName="settings.ini.bak" />
</Component>
</Directory>
If it matters, these components belong to:
<Feature Id="Default" Level="1">
<ComponentRef Id="settings.ini" />
<ComponentRef Id="Backup" />
</Feature>
I suspected this does not work because action MoveFiles runs after RemoveFiles and then there's nothing left to move, so I removed settings.ini from installer and copied it manually after installation. I was thinking this way the ini file is still there after RemoveFiles and it will be renamed. Well, the ini file is there indeed but it doesn't get renamed. Any idea why?
Windows Installer doesn't have a built-in mechanism for backing up and restoring files. Usually the solution is to use a custom action which copies the file.
I removed settings.ini from installer
and copied it manually after
installation. I was thinking this way
the ini file is still there after
RemoveFiles and it will be backed-up.
Well, the ini file is there indeed but
it doesn't get backed-up.
Try creating an uninstall log and see what happens when MoveFiles is executed. As a side note, I don't see how copying the file manually after install is better than a backup custom action.