I have a setup package including a non-compressed file.
<DirectoryRef Id="INSTALLLOCATION">
<Component Id="LocationConfig">
<File Id="LocationConfigFile"
Source="LooseFile.Config"
DiskId="2"
Vital="no"
Compressed="no" />
</Component>
</DirectoryRef>
The purpose of this file being loose is so it can be edited before installation. This works as desired.
I have a burn chain specifying that the loose file is included as a loose file alongside the bootstrapper. Note also the use of SuppressLooseFilePayloadGeneration to allow the manual specification of the file as a loose payload.
<Chain>
<MsiPackage SourceFile="MyInstaller.msi"
Visible="yes"
Vital="no"
SuppressLooseFilePayloadGeneration="yes">
<Payload Compressed="no" SourceFile="LooseFile.Config" />
</MsiPackage>
</Chain>
The burn log looks like this:
[3860:38D8][2013-04-26T16:42:48]e000: Error 0x80091007: Hash mismatch for path: C:\ProgramData\Package Cache\.unverified\payAC32431CF002C09E2F0B537A32ACA259
[3860:38D8][2013-04-26T16:42:48]e000: Error 0x80091007: Failed to verify hash of payload: payAC32431CF002C09E2F0B537A32ACA259
[3860:38D8][2013-04-26T16:42:48]e310: Failed to verify payload: payAC32431CF002C09E2F0B537A32ACA259 at path: C:\ProgramData\Package Cache\.unverified\payAC32431CF002C09E2F0B537A32ACA259, error: 0x80091007. Deleting file.
[3860:38D8][2013-04-26T16:42:48]e000: Error 0x80091007: Failed to cache payload: payAC32431CF002C09E2F0B537A32ACA259
[33FC:3A54][2013-04-26T16:42:48]e314: Failed to cache payload: payAC32431CF002C09E2F0B537A32ACA259 from working path: C:\Users\Snixtor\AppData\Local\Temp\{c887e0cf-5038-4e15-95b1-8510d8c96b88}\payAC32431CF002C09E2F0B537A32ACA259, error: 0x80091007.
OK, the hash is failing because the file has changed. But... I want to allow the user to change the file. I can readily enough do this with a standard setup package, so what hoops do I have to jump through to get it to behave with a bootstrapper?
I found this discussion in the WiX users mailing list. Robs response of "It should just work" sounds promising, but then the discussion seems to move on to suggest it could be a bug? If the author ever raised a bug report, I can't find it.
An alternative I considered was to exclude the file altogether from the bootstrap payload, and then manually copy it over to the MSI cache path during install so the MSI can find it, though burn will never try to validate it. But the two troubles I see there are:
I can't find out how to discover the cache path from within my bootstrapper.
Even if I knew the path, I'd need to elevate the bootstrapper to copy the file. That may not be a showstopper, but I have a sneaking suspicion it might prove difficult.
This isn't supported today. Burn validates everything before placing it in the cache for security reasons. What you could do is read the external file in a custom Bootstrapper Application and store the results as persisted Variables. This will be more work but Burn just won't trust files that don't match the security hashes/signatures inserted at build time.
I worked around this same issue by hanging off the current directory property that the burn bootstrapper sets and using it with a copyfile element like so:
<Component Id="SettingsFile" Guid="...">
<CopyFile Id="Copy" Delete="no" DestinationDirectory="INSTALLFOLDER" SourceName="LooseSettings.xml" SourceProperty="CURRENTDIRECTORY" />
<RemoveFile Id="Remove" On="uninstall" Directory="INSTALLFOLDER" Name="LooseSettings.xml" />
</Component>
There are quite possibly some issues with it but I'm writing an installer to someone else's specs and it seems to work
Related
When uninstalling my application, I'd like to configure the Wix setup to NOT to remove few files that were added as part of the installation. It seems like the uninstaller removes all the files that were originally installed from the MSI file. How do I do that?
Here are my files which I wish to keep it forever
<Binary Id="RootCABinary" SourceFile="Assets\Certificates\RootCA.cer" />
<Binary Id="SubCABinary" SourceFile="Assets\Certificates\SubCA.cer" />
I have used WixIIsExtension.dll to install these certificates to the windows store.
Overwrite: Is it important that the file never gets overwritten? If so, add
"Never Overwrite" to your component. WiX attribute: NeverOverwrite="yes". Remember to test upgrade scenarios!
Permanent Component: As stated by Pavel, you can set a component permanent:
<Component Permanent="yes">
<File Source="License.rtf" />
</Component>
Blank GUID: Another way to do it is to set a blank component GUID. It essentially means "install and then leave alone". No repair or uninstall should be done (remember to add NeverOverwrite="yes" if the file should never be overwritten):
<Component Guid="" Feature="MainApplication">
<File Source="SubCA.cer" KeyPath="yes" />
</Component>
Read-Only Copy: I sometimes install files to a per-machine path (for example somewhere under program files) and then copy them to a per-user location (somewhere in the user-profile) on application launch, and then do operations on them that entail that the files should not be deleted. This is good in cases where you want to do something that change the files in question (they need to be writable). Then it is good to "untangle" them from deployment concerns (files will not be meddled with by installer operations at all - the installer has no knowledge of them). The original read-only copy installed to program files can be uninstalled though (no longer needed?).
Other approaches: You can also create such files using custom actions during installation (usually text files only), you can download the file in question from your web site on application launch (makes the file easy to manage and update / replace? Vulnerable to connection problems - firewalls, etc...) and the application can create the file using "internal defaults" in the main executable on launch. And there are no doubt further approaches that I can't recall.
Put your binaries in a separate WiX component and make it permanent. Have a look at this thread as well
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
According to this, to retain user-customized files during a Windows Installer major upgrade I need:
1. Place each .config file in its own component and mark the .config file as the key path of the component.
2. Schedule the RemoveExistingProducts action in the new version of your MSI after the InstallFiles action.
<Component Id='config.json' Guid='GUID'>
<File Id='config.json' Name='config.json' DiskId='1' Source='config.json' KeyPath='yes' />
</Component>
...
<InstallExecuteSequence>
<RemoveExistingProducts Before="InstallFiles"/>
</InstallExecuteSequence>
There is following warning during build:
warning LGHT1076 : ICE63: Some action falls between InstallInitialize
and RemoveExistingProducts.
There is following error during installation:
The installer has encountered an unexpected error installing this
package. This may indicate a problem with this package. The error code
is 2613.
What is wrong?
The simplest way to handle this problem is to design your application so that user modified data is in it's own files. This way the installer can then own the files it lays down and the application can merge the two sets of data at runtime. MSI won't delete or overwrite what it doesn't know about.
Otherwise you get into complicated discussions of how to merge xml/json and other file types during an upgrade.
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.
I have WCF in IIS. WCF uses log4net logs. How I can remove log folder on uninstall?
The log folder is in target folder.
I use this piece of code:
<Directory Id='Logs' Name='Logs'>
<Component Id="comp_iislogs" Guid="{0B0E2F6E-008D-42C9-8A7C-1F1265C077A1}"
SharedDllRefCount="no" KeyPath="no" NeverOverwrite="no" Permanent="no" Transitive="no"
Win64="no" Location="either">
<RemoveFile Id="Files" On="uninstall" Name="*.log"></RemoveFile>
<CreateFolder/>
</Component>
</Directory>
The problem is log file is in use on uninstallation and uninstaller says please stop app etc...
You'll have to kill the process that has the logfile open then! If that's something in a web app then you'll probably only have to recycle the application pool for the handle to be released (I think).
You can do that using appcmd recycle apppool /apppool.name: <pool name> from within your WiX scripts. You might want to actually stop then restart site however just to avoid any chances of it being open at the time.
MSI removes only files it copied during initial installation.
Logs generated by the application are not recognized by the uninstall process.
In other words, if at least one file exists in a directory to be removed, MSI will treat it as user file and skip its parent directory from removal.
In order to remove log directory you need to forcefully delete its contents first, but I would advise against that as you may encounter locking issues you don't want to deal with.
Use RemoveFolderEx element from Util extension in WiX.
With this approach, all the subdirectories and files are removed.
Example:
<util:RemoveFolderEx On="uninstall" Property="Logs" />
Place this inside the Component tag.