Install merge module for all users using WiX - wix

I created an Installer using WiX to install a VSIX along with two dependent components. These two components were available to me in the form of Merge Modules. Below is the code where I used the merge modules in my code:
<DirectoryRef Id="TARGETDIR">
<Merge Id="MergeModuleID1" SourceFile="MergeModule1.msm" DiskId="1" Language="0"/>
<Merge Id="MergeModuleID2" SourceFile="MergeModule2.msm" DiskId="1" Language="0" />
</DirectoryRef>
and I've referred these merge modules as:
<Feature Id="ProductFeature" Title="Title" Level="1">
<ComponentRef Id="VSPackage"/>
<ComponentRef Id="ApplicationShortcut"/>
<ComponentRef Id="DesktopShortcut"/>
<ComponentRef Id="LicenseComp"/>
<MergeRef Id="MergeModuleID1"/>
<MergeRef Id="MergeModuleID2"/>
</Feature>
The problem I'm facing is, that my VSIX is installed to all the user accounts on the machine, but these merge modules are not, they're installed only on the user account where the product is installed. On other user accounts, an installation dialog appears, which I believe is installing these merge modules, after which everything works fine.
How do I make these merge modules to be installed to all users?
P.S: ALLUSERS property in both the MSI and merge modules are set to '1'.

You may need to clarify that question somewhat. Merge modules are not installed, just the files, so you mean the files in merge modules are going somewhere incorrect, yes? Also, files are not installed on a user account they got to a location on disk.
Guessing my way through this, you're probably saying that the files get installed to somewhere like the User's Application Data location for the installing user. If that's what the merge modules specify in their internals, that's normal. You can obviously install files to the current user's application data folder even if you're doing a per machine install. I can't say if those merge modules are correctly designed or not, but if they are then:
The initial install will put those files in the installing users file location.
If another logs on and uses a shortcut and your MSI is correctly designed, the install-on-demand feature will install those files for that user in that user's folder, maybe asking for the original install media. That's the way this is designed to work because:
a) There is no mechanism that that allows a file to be installed simultaneously to all user file locations on the system, and it makes no sense anyway if they never use the app.
b) What happens if you create a new user account AFTER the product has been installed? The file will not be in that user's location, however the install on demand scheme guarantees that this new user will get the file in their location if they log on and use the app.
The short answer is that this is probably all working as intended.

Setting ALLUSERS is fine.
What you've described looks like "advertising".
To remove advertising for the Merge Modules, add AllowAdvertise="no" to the Attributes of the Feature containing the MergeRef element :
<Feature Id="ProductFeature" Title="Title" AllowAdvertise="no" Level="1">
<ComponentRef Id="VSPackage"/>
<ComponentRef Id="ApplicationShortcut"/>
<ComponentRef Id="DesktopShortcut"/>
<ComponentRef Id="LicenseComp"/>
<MergeRef Id="MergeModuleID1"/>
<MergeRef Id="MergeModuleID2"/>
</Feature>

Related

WIX. How to not reinstall a feature during repair?

In WIX I'd like a feature to be installed and uninstalled normally but not to be touched during repair.
I was not able to find a condition which would allow me to do this.
My attempts has failed: the feature is reinstalled on repair (what I do not need) or is not uninstalled.
This is a sample that I tried last:
<Feature Id="aFeature" Title="A Features" Level="1">
<ComponentRef Id="aComponent" />
<Condition Level="0">
<![CDATA[WixUI_InstallMode="Repair"]]>
</Condition>
</Feature>
What is the right condition to uninstall but not re-install during repair?
Or what did I do wrong?
This works for me:
<Feature Id="aFeature" Title="A Features" Level="1">
<ComponentRef Id="aComponent" />
<Condition Level="0">
<![CDATA[REINSTALL<>""]]>
</Condition>
</Feature>
This way during Repair the feature is ignored and not touched, but normally uninstalled
The only way I can think of is to give all the components in that feature an empty guid, that's the signal to Windows Installer not to do anything with them, such as repair them, patch them, uninstall them. If the product is already shipped it's too late for that. However that's a drastic step that is normally necessary only when you want to install some things for temporary use and then delete them. So you are fighting the framework here. It's look like you have a problem that disabling feature repair might solve, so why not describe the problem to see if there is another solution?

Wix - third party software reinstalls everytime app is run

My application installs the DesKey Dk2 dongle drivers if they are not installed or are lower than a perticular version. One of the user is complaining that whenever he runs the application from start menu shortcut, DK2 installation starts and then application is launched. Nobody else is facing this issue.
I am indtalling Dk2 as custom action in Wix script as below. lets say DK2 is represented as ABC:
<DirectoryRef Id="TARGETDIR">
<Directory Id="ABCRedistDirectory" Name="ABCDrivers">
<Component Id="ABCRedist" Guid="*">
<File Id="ABC_EXE" Source="$(var.TargetDir)ABC.exe" KeyPath="yes" Checksum="yes"/>
</Component>
</Directory>
</DirectoryRef>
<Property Id="DK2_VERSION">
<RegistrySearch Id="Dk2_Version"
Root="HKLM"
Key="SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\DESkey DK2 Uninstall"
Name="DisplayVersion"
Type="raw" />
</Property>
<Feature Id="ABCRedist" Title="ABC drivers" AllowAdvertise="no" Display="hidden" Level="1">
<ComponentRef Id="ABCRedist"/>
</Feature>
<CustomAction Id="InstallDK2Drivers" FileKey="ABC_EXE" ExeCommand="" Execute="deferred" Impersonate="no" Return="check"/>
<InstallExecuteSequence>
<Custom Action="InstallDK2Drivers" Before="InstallFinalize">
<![CDATA[NOT DK2_VERSION OR DK2_VERSION < "7.34.0.57"]]>
</Custom>
</InstallExecuteSequence>
The warning in Windows Event viewer points to main executable, which is below:
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="FolderName">
<Directory Id ="MyFolder" Name="MyApp">
<Component Id ="MyApp.exe" Guid="*">
<File Id="MyApp.exe" Source ="$(var.TargetDir)MyApp.exe" KeyPath="yes" Checksum ="yes" />
<Shortcut Id="MyAppStartMenuShortcut" Name="My App" Directory="ProgramMenuDir" Icon="MyAppIcon.exe" WorkingDirectory="MyFolder" Advertise="yes"></Shortcut>
<Shortcut Id="MyAppDesktopShortcut" Name="My App" Directory="DesktopFolder" Icon="MyAppIcon.exe" WorkingDirectory="MyFolder" Advertise="yes"></Shortcut>
</Component>
...
Now it is not happening on other machines so I am not able to diagnose. Can anybody point out any obvious mistake? What can I do to diagnose this on customer's machine i.e. how to get logs when installing .exe, .dll, some third party installers like VC100 CRT and VC100 MFC and .Net 4.0 bootstrapper?
Thanks in advance.
I can't tell from your post if the 3rd party ABC product that you're using is the same one that is repairing, or maybe the client doesn't know and you're assuming that it is your ABC thing. There's no indication in that WiX fragment exactly how you're installing the ABC thing, all you show is that it's copied to disk, there's no clue how you are running it to get it installed, and no shortcuts either.
What's happening in general seems to be that the other product is going into repair mode. There should be MsiInstaller entries in the Application Event Log that say something about whatever is wrong, referencing component ids, products, and maybe file names or registry entries.
Your setup may have a conflict with that other install. It's unlikely to be anything to do with your shortcut except that your shortcut is advertised, so it goes off into a component feature check, and is apparently finding that you are sharing something with that other app, and now it needs repairing. If the 3rd party app that repairs is not your ABC thing then you won't be able to reproduce the issue unless you also install that 3rd party thing and find out what you're sharing with it, perhaps in the wrong way.
Is this some sort of bit-torrent component? I see an abc project on sourceforge.net with Python dll's, some visual C++ runtimes included as well as other stuff. This is by no means a properly constructed package, and it could trigger the self-repair problems seen on that particular computer.
To debug this would require to see what entries exist in the Windows Event log - it will specify what MSI component triggered the repair. The error could still be in other packages since a COM call from the embedded components in this abc package, could trigger a repair in any MSI package installed on the system. As could taking over a file association associated with torrent files.
Right click My Computer
Select Manage
Event Log -> Windows Logs -> Programs
In this log you will find entries starting with "Description: Detection of product..." with id 1001 or 1004. Here is a sample:
Event ID: 1001
Description: Detection of product "{4ED0C75A-8BC5-4520-B9C7-76968FD5677F}", feature "Test" failed during request for component "{A7B09747-E527-4E1B-AE51-323CD636210F}"
This information is enough to determine what package triggered the self-repair. Please provide this information and we can take it from there.
I extracted the above sample information from Stefan Krüger's MSI FAG at installsite.org.
You are using advertised shortcuts. In your Shortcut elements, set Advertise="no" or remove the Advertise attribute completely.
For more information, see this SO answer and msdn.

Wix: Feature tree selections cause Browse button to disappear

In my installer, I have two features. If I disable one feature, the Browse button (and the edit control containing the INSTALLDIR path) disappears from the UI. I suspect this is because both Feature elements use the same ConfigurableDirectory="INSTALLDIR" attribute:
<Feature Id="MYCLIENT" AllowAdvertise="no" ConfigurableDirectory="INSTALLDIR"
Title="Client component"
Description="Client Component" Level="1">
<ComponentGroupRef="Client1"/>
</Feature>
<Feature Id="MYMMC" AllowAdvertise="no" ConfigurableDirectory="INSTALLDIR"
Title="MMC Components"
Description="MMC Components" Level="1">
<ComponentGroupRef Id="MMC1"/>
<!-- MMC snap-in requires some client components -->
<ComponentGroupRef Id="Client1"/>
</Feature>
What would I need to implement to prevent the INSTALLDIR Browse controls from disappearing when a feature is de-selected/not installed ?
TIA
Browse button is related to the selected feature in the tree. If you have excluded some feature and it is still selected, it is logical that there is no sense to set install path for this feature. So Browse button is disabled. I suppose when you select another feature in the tree, the Browse button will appear again.
By the way, why do you need the same ConfigurableDirectory for both features? That's a bit strange to install 2 main parts of the system in the same folder. I usually make a root Feature with ConfigurableDirectory while all sub-features can only be installed in predefined sub-folders. On the other hand, if you really need to set different locations for 2 features, you'd rather use differect ConfigurableDirectories.

WiX: keep (rename) file on uninstall

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.

Sequencing Components in Feature Element

I want to replace a file that has been installed by my installer. In the following code the "OneCoreFiles" component should install the files first time( which is working) and the component "ConfigCopyFile" should replace that config file.
But the code is not working as expected. The component 'ConfigCopyFile' is getting executed first and then the 'OnecoreFiles'. I want it to work the other way.
I am still learning WIX and thought that the components in Feature elements are executed in the order in which they are declared.
Code Snippet:
<Component Id="ConfigCopyFile" Guid="{98E61055-5A84-4003-90D1-7A67677D7465}">
<Condition>CONFIGFILEEXISTS</Condition>
<CopyFile Id="ConfigFileId" SourceProperty="CONFIGFILEEXISTS" DestinationProperty ="INSTALLDIR"/>
</Component>
<Feature Id="ProductFeature" Title="OneCore Features" Level="1">
<ComponentRef Id="LogEntries" />
<ComponentGroupRef Id="OneCoreFiles" />
<ComponentRef Id="AppDBConfiguration" />
<ComponentRef Id="SqlServerConfiguration" />
<ComponentRef Id="OracleConfiguration" />
<ComponentRef Id="IISConfiguration" />
<ComponentRef Id="ConfigCopyFile" />
</Feature>
This must be quite simple to solve. Am I missing something. Please advice.
You are thinking of WiX in the wrong way. It's not a scripting language. It's a way of representing Windows Installer databases which are declarative in nature not imperative. If I list a bunch of components and files it's non deterministic the order the files will be copied. I'm only saying that these files need to be installed not how to install them.
Windows Installer does expose sequence tables which drive the order of things ( such as create folders then copy files ) but it doesn't micromanage to the level of copy this file before that file.
Suggested InstallExecute Sequence
InstallExecuteSequence Table