I created a WIX Installer without really knowing a ton about WIX. I do like that I know what I am installing, where I am installing it, and how to create the setup application. However - I can't seem to figure out how to give checkboxes for each feature.
For example, I set my program up to have 2 features:
<Feature Id="AdminClient" Title="Admin Client" Level="1">
</Feature>
<Feature Id="AppDB" Title="Application Database" Level="1">
</Feature>
For this application, I want the installation to allow the user to check the boxes of the stuff they want to install. For example - quite often the user will already have an application database and I do not want to overwrite that database.
I will also be adding other optional features and would like to have selection options for those.
I've played around with WixUI_Advanced and WixUI_InstallDir - but didn't see a way to do it with either. But, again, I'm not great at this yet.
The WixUI_FeatureTree and WixUI_Mondo dialog sets expose a feature selection dialog.
Related
My wix installer creates the shortcuts at Desktop and StartMenu during installation.
From the installed Startmenu shortcuts, Some of the users use the feature "Pin to taskbar" to pin the shortcuts to taskbar manually which is not in control of my wix msi.
The taskbar shortcut gets created at %AppData%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Product.lnk in Windows 10.
The shortcuts at StartMenu and Desktop gets removed when product is uninstalled (which is expected), However the taskbar shortcut pinned manually goes orphaned and stays even after product is uninstalled.
How can i remove the taskbar shortcut when product is uninstalled ?
This is what I tried but it is not working:
<CustomAction Id="DeleteTaskBarShortcut" Execute="deferred"
ExeCommand="del "[AppDataFolder]\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Product.lnk""
Directory="AppDataFolder"
Impersonate="no"
Return="ignore" />
<InstallExecuteSequence>
<Custom Action="DeleteTaskBarShortcut" Before="RemoveFiles">Installed</Custom>
</InstallExecuteSequence>
Thanks in advance
To answer the question of Should you the answer would be no. The reasons are:
Microsoft has made it incredibly difficult to manage things like this because they consider it user data and they don't want software vendors abusing user settings.
Your user created the object not your installer. So therefore you are under no obligation to clean it up.
Managing per-user resources for a per-machine installer has always been incredibly difficult anyways. It creates a many to one cleanup with access right issues to boot.
If you are somehow able to run an EXE that when ran as SYSTEM works as expected then I can assist you in integrating that into an MSI. But don't expect it to always work especially on newer versions of Windows as MSFT continues to close off the attack surfaces.
I have 5 installers some that might need to be installed on the same machine and others else where. Each has its own set of custom UI for user input, Setting up config options for the installed application.
I need the user to be able to pick which installers they want to run from the full installer. Something like how you choose features in the standard installer. However I still need these to be separate installers if the user prefers to just grab the needed msi.
Is there a way to add custom ui steps to the bootstrap installer like you would other wix project types?
The standard WIX Bootstrapper Application (WixStdBA) does not support this, you will have to customize the standard application code to acheive what you are looking for.
Instead of editing the stdba, you can take a look at the WIXEXTBA project in codeplex: WIXEXTBA. This project has already included some of the features that you are looking for.
To edit the standard BA at a high level you have to follow these steps:
InstallCondition attribute can be used to control whether a package should be installed:
<MsiPackage Id='MsiName' InstallCondition='RadioButton' SourceFile='\msiname.msi' />
Define your "RadioButton" variable:
<Variable Name='RadioButton` Value='1' Persisted='yes' />
Now define a relationship for your RadioButton to UI in the wixstdba. You can do this by overriding the Theme file and adding radiobutton to the Options page that use RadioButton as the #Id of the control.
Following on from my last question Why does my WiX Custom action throw a System.IO.FileNotFoundException?, I am now trying to get the C++ distributable installed as part of my msi.
I have followed the example as per the documentation; http://wix.sourceforge.net/manual-wix3/install_vcredist.htm
<DirectoryRef Id="TARGETDIR">
<Merge Id="VC_Redist" SourceFile="$(env.ProgramFiles)\Common Files\Merge Modules\Microsoft_VC100_CRT_x86.msm" DiskId="1" Language="0"/>
</DirectoryRef>
<Feature Id="Complete" Level="1" Title="$(var.NVRProduct) $(var.NVRVersion)" Description="Everything" Display="expand">
<Feature Id="VC_Redist" Title="Visual C++ Runtime" AllowAdvertise="no" Display="hidden" Level="1">
<MergeRef Id="VC_Redist"/>
</Feature>
</Feature>
It does not work. The C++ distributable is not installed, and subsequently my msi throws an error as the C++ distribution is missing, and uninstalls itself.
This seems to be the same as this question, which was not really answered.
C++ Redistributable package with WIX
Any ideas appreciated.
I am going to answer my own question as there are a number of issues I found out after further investigation.
Firstly, the install of the VC++ merged module was actually working!
I didn't think it was because I was still getting an error, and I couldn't see an entry for the VC++ runtime in the Add Remove programs like you can if you install it manually.
However, by changing the installation to only install the distributables and the application up to where I received the error, I could see the VC++ dll was actually being installed. The error I was now seeing was because the program required the ATL redistibutable as well. (As I discovered through using Dependency Walker). The error caused the msi to fail, and the VC++ dll was being uninstalled along with the rest of my application dlls!
Once I provided the VC++ and the ATL distributables using the mechanism as per the example in the help file, all was well.
I have also used the statically linked SQLite dll as even with the distributables being installed, the initial calls to SQLite from the custom action were failing. I think this must be due to an installation sequence issue. However, using the statically linked version has raised a degree of discussion among developers here, with around a 50-50 split in favour and strongly against using it.
The installation does now work, however.
Sounds like your custom action is either scheduled before the InstallFiles action or not deferred or both. You don't provide the custom action definition but make sure your CustomAction element has the Execute attribute set to 'deferred' and ensure your Custom element is in the InstallExecuteSequence scheduled After='InstallFiles'.
Alternatively, you might consider statically linking the CRT into your custom action. I always recommend this option since it makes your custom action stand alone which greatly increases the chance that the custom action will always work (including during install, repair, uninstall, and patching).
I need to deploy a software setup targeting both, Windows 64bit and 32bit. I have two separate Windows Installer databases (created with WiX) for each platform, and I am using dotNetInstaller to combine both into a single installation bootstrapper executable.
I'm currently using version 1.10 of dotNetInstaller and set auto_close_if_installed=True, because I want to comletely hide the bootstrapper from the user. Still, dotNetInstaller insists on displaying a sill progress bar window while my installer is running, and doesn't really auto-close. The user needs to confirm a dialog box telling him that the application was successfully installed. But the real deal-breaker is that it doesn't support Windows 8 (yet).
Upgrading to a later version of dotNetInstaller seems to break auto_close_if_installed, so it's even worse.
So my question is: what is the current state of the art to deploy both setups in a single executable. Would Wix Burn be an option?
I know that in an ideal world, I simply provide my customers with separate installers for either platform. But they happen to be completely unaware of such subtleties, most of them don't even know what platform they are using.
I would definitely use Burn in this scenario. Something akin to the following:
<Wix>
<Bundle...>
<BootstrapperApplicationRef Id='WixStandardBootstrapperApplication.HyperlinkLicense' />
<Chain>
<MsiPackage InstallCondition='NOT VersionNT64' SourceFile='path\to\x86.msi' />
<MsiPackage InstallCondition='VersionNT64' SourceFile='path\to\x64.msi' />
</Chain>
</Bundle>
</Wix>
This is exactly one of the scenarios Burn was designed to handle.
You can do it in a single Wix via Conditions and Features.
<Feature Id='X86' Level='1'>
<ComponentRef Id='X86Feature1' />
<Condition Level="1">NOT VersionNT64</Condition>
</Feature>
I have a WiX installer project that utilises a custom dialog box to ask for parameters to update a web.config file and run a database script on install. Everything works correctly and the application is installed and runs correctly.
However, the custom dialog box is also displayed when I uninstall the software and it certainly doesn't need to be (as I'm not updating a web.config file).
Is there a way to suppress the custom dialog when the application is being uninstalled?
(I should also remove the sql procs I install, at uninstall time but that is outside of this issue).
The solution to your question is to condition the custom action with the condition (Not REMOVE="ALL"). This will make the action run on fresh install and maintenance install, but not on uninstall. If you don't need to run on maintenance install, but only on a fresh install you can set the condition to be: (Not Installed AND Not(REMOVE="ALL")). Full list of MSI properties and brief descriptions here: http://msdn.microsoft.com/en-us/library/aa370905(VS.85).aspx.
The sequencing and custom action logic in MSI files is VERY complicated. It really pays off to avoid custom actions whenever you can.
There is more - all MSI files have built-in support for silent installation. This means that the entire GUI sequence can be skipped, and the MSI file installed without user interaction. This is a crucial feature for corporate deployment via SMS / SCCM or other deployment mechanisms. Showing a custom dialog box when the setup is run in silent mode is a violation of this basic MSI feature. You can work around this by properly conditioning the display of the dialog based on the property UILevel: http://msdn.microsoft.com/en-us/library/aa372096(VS.85).aspx. Just to keep things interesting and confusing Microsoft has defined 4 levels of GUI during an installation ranging from completely silent, through various options such as progress bar only etc... See the link for details.
I could add a lot of details here about MSI sequences, conditions, custom actions and similar, but it wouldn't answer your question. Please add any follow-up questions.
Wix snippet to show the creation of a custom action and its insertion into the InstallExecuteSequence:
<!--Custom Action Sample Section-->
<Binary Id='VBScriptCustomAction.vbs' SourceFile='VBScriptCustomAction.vbs'/>
<CustomAction Id='test' BinaryKey='VBScriptCustomAction.vbs' VBScriptCall='Hello' Return='ignore'/>
<InstallExecuteSequence>
<Custom Action="test" Sequence='4111'><![CDATA[NOT REMOVE~="ALL"]]></Custom>
</InstallExecuteSequence>
<!-- End of Custom Action Sample Section-->