I have a Wix (3.8) project that is relatively generic in that we are attempting to produce multiple Demo installers using a variety of tools such as the preprocessor to change the name, include different files and options. I also modify the ProductId/ProductCode/UpgradeCode for each so that they appear as 2 different products and install side by side. Installing and uninstalling one alone works fine. When I install 2 side-by-side and uninstall one there are several abandoned resources one of which is the shortcuts.
Here is the code I am using for the shortcuts:
<DirectoryRef Id="DesktopFolder">
<Component Id="DesktopShortcuts"
Guid="*">
<Shortcut Id="ApplicationDesktopShortcut"
Name="!(bind.property.ProductName)"
Description="Demo Application"
Target="[INSTALLDIR]Demo.exe"
WorkingDirectory="INSTALLDIR"
Advertise="no"/>
<RegistryKey Root="HKMU"
Key="SOFTWARE\$(var.Manufacturer)\!(bind.property.ProductCode)\DesktopShortcuts">
<RegistryValue Name="Installed"
Type="integer"
Value="1"
KeyPath="yes" />
</RegistryKey>
</Component>
</DirectoryRef>
After reviewing the installer logs I note that the ComponentId for the shortcuts is always the same which explains the abandoned resources (shortcuts).
I was under the impression that because the Path to my registry value was different for each installer (note that I bind the product code into the key) I would get a different Guid for each installer as a result of the Guid="*" attribute. However, the wix documenation is unclear WRT Registry keys as are other discussions I located. Apparently this isn't an issue with files that are in separate directories.
Such as this and the Wix docs.
So I figured out what is going on. It's all got to do with some subtle issues on this line:
Key="SOFTWARE\$(var.Manufacturer)\!(bind.property.ProductCode)\DesktopShortcuts">
As noted in the question the documentation and references suggest that the Path for files and registry entries are used to dynamically generate the Guid. Note the path includes the file/Value Name. This is in fact happening but how was I getting the same Guid for the ComponentId for 2 different installers using 2 different ProductCodes? You would think that the inclusion of the ProductCode into the path would make each unique. Well, turns out it's because I was using !(bind.property.ProductCode) in the path. Binder variables don't get substituted until the Linking phase with light. The Guid="*" element is generated in the Compiling phase with Candle which is obviously before the linker. So while the substitution was occurring and the proper keys were being generated in the registry, the Guid was being generated from a non unique path:
SOFTWARE\MyCompany, Inc\!(bind.property.ProductCode)\DesktopShortcuts\Installed
So don't use binder variables in any KeyPath element when using the auto generated Guid functionality.
Related
I have Wix project in which I need a common used dll library to be installed if it's absent.
If this dll exists I should not overwrite it.
So, when I set DefaultVersion="0.0.0.0" this dll is not overwritten if it exists, its ok. But when I delete app, the dll is beeing removed. How do I prevent removing dll in the case when it existed before installation?
I don't want to make it permanent because it should be removed if it didn't exist before installation.
<Component Id="myLib.dll" Permanent="no" Directory="Shared_Dir">
<File Name="myLib.dll" KeyPath="yes"
Source="mySource\myLib.dll"
DefaultVersion="0.0.0.0"
/>
Add reference to WixUtilExtension and xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" attribute to Wix element in your code.
Define <Property Id="Dll_Installed" Value="false"/> in Product element.
Add child <Condition>NOT Dll_Installed</Condition> to component myLib.dll.
Add that somewhere in your code:
<Fragment>
<util:FileSearch
Id="Dll_Installed"
Variable="Dll_Installed"
Path="[Shared_Dir]myLib.dll"
Result="exists"/>
</Fragment>
DefaultVersion attribute is not necessary.
The feature you are describing is reference counting. The Windows Installer reference counts with Components. Components are identified by their GUID.
So the normal way to address this requirement is to put the File in a Component and make sure the GUID of the Component is stable. The WiX Toolset should do exactly that automatically if if you do not specify the Component/#Guid attribute.
So the default behavior should just work for you.
The only other piece of the puzzle is the Windows Installer will install the latest version of a file. If the file version is the same or less the file will not be installed but will be reference counted.
Based on the details in the question it seems like you should be just fine with:
<Component Directory="Shared_Dir">
<File Source="mySource\myLib.dll" />
</Component>
One might ask why the Windows Installer use Components to reference count files. We'll, it allows you to group other resources, like registry keys, together and control their install as a unit. Much more important if you are installing COM servers than plain old files.
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
When adding a merge module (Visual FoxPro Oledb V9) to a wix project, I get the following error message:
error LGHT0204: ICE32: Possible Mis-Aligned Foreign Keys
Using WiX Toolset v3.11
I get no indication of the table in which the keys are misaligned from the output.
I have tried opening the vfpoledb.msm in Orca, but I can't seem to find anything that looks like it is mismatched in terms of field sizes.
The merge module is being included with:
<Directory Id="TARGETDIR" Name="SourceDir">
<Merge Id="VFPOleDb" SourceFile="$(var.resources)\vfp-ole-db-merge-module\vfpoledb.msm" DiskId="1" Language="0"/>
...
</DirectoryRef>
<Feature Id="MainApplication"
Title="Application Title"
Level="1"
ConfigurableDirectory="INSTALLDIR"
Absent="disallow">
<MergeRef Id="VFPOleDb" />
<ComponentGroupRef Id="MainComponents" />
<ComponentGroupRef Id="ShortcutComponents" />
</Feature>
This merge module was previously included in an InstallShield installer project with no apparent issues. I've since converted across to using Wix but can't seem to get the installer to build with this merge module included (other merge modules are included e.g. vc++ runtime).
I can confirm that removing the merge module from the xml with no other modifications then allows the installer to build (removing the Merge and MergeRef elements for the merge module).
I've searched the internet to try and find suggestions to resolve this, with the only page I can find suggesting adjusting the table schema using Orca, but as mentioned, I get no further info on what table is causing the problem.
Any advice appreciated on how to either resolve the issue, elicit more information as to the offending table within the .msm.
Build from the command line and you'll get the misalignment(s). Visual Studio won't show multiple lines for a single error.
Run validation on the built MSI to see which tables are effected then use the EnsureTable element to tell WiX to put this empty table in. This will happen prior to merging of the merge modules and will make the error go away.
When I create a Windows Installer package (say using WiX) and I install the application App.exe as well as the App.exe.config should the config file have its own component or should it be a companion file to the application executable?
<Component Id="C.App.exe">
<File Source="App.exe"/>
</Component>
<Component Id="C.App.exe.config">
<File Source="App.exe.config"/>
</Component>
versus
<Component Id="C.App.exe" Guid="PUT-GUID-HERE">
<File Id="F.App.exe" Source="App.exe"/>
<File Source="App.exe.config" CompanionFile="F.App.exe"/>
</Component>
If I install different App.exe.config files depending on some external property (say run-time environment like test or release) does that affect what choice I should make?
The answer is it depends. Rob's article mentioned by Yan is a good read, here is another:
Defining Installer Components
http://msdn.microsoft.com/en-us/library/aa368269(VS.85).aspx
The trick is to understand how costing and repairs are based on keyfiles, how the default versioning rules work, how you plan on servicing your application in the future and making your decision based on that.
It is recommended to put a single resource (file, registry key, etc.) into a single component. In this case this resource is a KeyPath of the component. Windows Installer watches the key path of each component to decide if it worth installing, repairing, upgrading, etc.
This article of Rob Mensching explains the things in detail.