I am trying to get the Options button on the WixStandardBootstrapperApplication to be hidden if the application has already been installed.
I was hoping to be able to pass a variable to SuppressOptionsUI. But it seems the value of SuppressOptionsUI must be a literal yes or no.
This was the code I was using.
<!-- Don't show options button if we have an existing install -->
<Variable Name="suppressOptions" Type="string" Value="no"/>
<util:DirectorySearch
After='PreviousInstallFolderSearch'
Condition='PreviousInstallFolder'
Path='[PreviousInstallFolder]'
Result="exists"
Variable="suppressOptions"/>
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.HyperlinkSidebarLicense">
<bal:WixStandardBootstrapperApplication
ShowVersion="yes"
LicenseUrl="http://static.my-site.com/EULA.html"
LogoFile="Installer-Banner.bmp"
LogoSideFile="Installer-FirstPage.bmp"
SuppressOptionsUI="[suppressOptions]"
/>
</BootstrapperApplicationRef>
So my question is: Is there another way of configuring the WixStandardBootstrapperApplication to allow SuppressOptionsUI to be configurable based upon a variable populated from a registry or directory search?
NB I am using the WixToolset only. No VBA or other MS tools.
"Not today™"
This is an open issue, available for the taking: WixVariable to SuppressOptionsUI.
Related
I am creating a Bundle installer, using WiX standard bootstrapper in order to install .NET Framework 4.5 (if not yet installed) and my application in the user's computer. The bundle installer also allows the user to set the installation path for the application, and uses WiX standard bootstrapper's UI only (no other installers' interfaces are shown to the user).
Right now I'm struggling to allow the user to launch my application at the end of the installation.
Closest related anwers I could find use a variable named LaunchTarget, which causes WiX standard bootstrapper to display a "Launch" button in the end of the installation.
Given solutions and why I wasn't able to use them follow:
Answer "A" suggests setting the LaunchTarget variable to the exact folder inside "Program Files" folder where the application should be installed. This doesn't work for me, because I want to allow the user to specify the target installation folder (application can be installed outside of the "Program Files" folder).
Answer "B" suggests setting the LaunchTarget variable by using the InstallFolder variable to determine where the user configured the standard bootstrapper to install the software to. This seemed perfect for my case, but after setting the LaunchTarget value simply to "[InstallFolder]" I verified that pressing the "Launch" button in the standard bootstrapper's UI actually opens the folder where the installer is running, and not the folder where the user chose to install the software, as I expected. (is that a bug?)
Question is: how can I correctly set the LaunchTarget variable to the right path, considering that the user can modify the installation folder through WiX standard bootstrapper's UI?
The code for the Bunde follows.
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="My Game Trainer" Manufacturer="MY_MANUFACTURER_ID_HERE" UpgradeCode="MY_GUID_HERE" Version="!(bind.packageVersion.TrainerMsiPackage)" DisableModify="yes">
<Variable Name="LaunchTarget" Value="[InstallFolder]" />
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLargeLicense">
<bal:WixStandardBootstrapperApplication ShowVersion="yes" LicenseFile="PATH_TO_MY_LICENSE.rtf" />
</BootstrapperApplicationRef>
<Chain>
<PackageGroupRef Id="NetFx45Web"/>
<MsiPackage Id="TrainerMsiPackage" SourceFile="$(var.SetupMSI.TargetPath)" DisplayInternalUI="no">
<MsiProperty Name="TRAINER_INSTALL_DIR" Value="[InstallFolder]"/>
</MsiPackage>
</Chain>
</Bundle>
</Wix>
Using WiX Toolset v3.11.1 (+Visual Studio 2017 Extension).
I have written following code in my wix installer for updating the language in an XML file and this works fine in following conditions:
1) fresh install
2) upgrade by using admin rights (I am using msiexec /I "Tools.msi" /l*v D:\InstallLog.txt).
However, when I run/execute the msi without admin rights (This is where "Change" mode is being used....what am I missing) the values are not updating always set to the default value :
<Property Id="LANGUAGE" Value="en-US" />
The code:
<util:XmlFile Id="LanguageConfig"
Value="[LANGUAGE]"
ElementPath="/configuration/appSettings/add[\[]#key='Language'[\]]"
Action="setValue"
File="$(var.ConfigFile)"
Name="value" Sequence="1" />
<util:XmlFile Id="MappingLanguageXML"
Value="[LANGUAGE]"
ElementPath="/MappedUsers/UsersList/UserID/LanguageCode"
Action="setValue"
File="$(var.UserMappingFile)" Sequence="1" />
Any help is much appreciated.
The fact that it's being changed implies it may not be a privilege issue. I suspect that the scenario is that a different language was entered at install time, but you did not preserve its value anywhere so Change just uses the default value. Properties aren't remembered automatically, that's what the WiX "remember property" pattern is for. That's likely to be the solution - preserve the install time value of LANGUAGE. It's no different from running any program - the fact that the user may have entered something that went into a variable doesn't mean that the variable will have that same value next time you run the program unless you save it.
Based on PhilDw pointer I solved the issue by modifying my property
<Property Id="LANGUAGE" Value="en-US" />
as follows:
<Property Id="LANGUAGE" Secure="yes" Value="en-US">
<RegistrySearch Id="RememberLanguage" Root="HKLM"
Key="$(var.RegistryLoc)"
Name="Language" Type="raw" />
</Property>
By preserving the value in the registry I was able to modify the value during "Change" operation.
I'm trying to do an installer using wix 3.8. I can use custom properties to store my own input, but I'd like to use values that where inputs on a previously installed msi.
Is there a way to accomplish such thing?.
To get you in the right direction add this (of course adapt it to your needs first) in your fist MSI:
<DirectoryRef Id="INSTALLDIR">
<Component Id="RegistryEntries" Guid="{0AC76129-F8E2-47D3-B9FD-09B1E10A8541}">
<RegistryKey Root="HKLM" Key="Software\Company123\App123" Action="create">
<RegistryValue Type="integer" Name="SomeIntegerValue" Value="1" KeyPath="yes"/>
<RegistryValue Type="string" Name="UserInput" Value="[USERINPUT]" />
</RegistryKey>
</Component>
</DirectoryRef>
Don't forget reference the component in your <Feature> <ComponentRef Id="RegistryEntries" />
When you install assign a value to the property [USERINPUT] e.g. msiexec /i your.msi /qb+ USERINPUT="the value to be saved in registry"
Then in the second MSI add something like this:
<Property Id="READREGISTRY">
<RegistrySearch Id="USERINPUT_Value" Root="HKLM" Key="Software\Company123\App123" Name="UserInput" Type="raw" />
</Property>
The value/string you entered during installation USERINPUT= will be stored in your second MSI in the property READREGISTRY
Here a piece of log in my second msi:
PROPERTY CHANGE: Adding READREGISTRY property. Its value is 'testing registry wef wef wef w'.
Based on your installation where it might be Per User or Per Machine you may adjust the Root to HKCU for PerUser installs or leave it to HKLM for PerMachine.
For more information please refer to Wix documentation, hints: "How To: Write a Registry Entry During Installation" and "How To: Read a Registry Entry During Installation".
Generally, no. There is no requirement for a Windows Installer package to record the input it takes from the user. Some do record some information in the registry and you might choose to rely on finding it there.
As an alternative, you might find that the other installer can be run without a UI and can be sufficiently controlled with properties passed into it. If so, you can write your own UI (one way would be a custom WiX Bootrapper Application [example]) to gather the inputs before running the installer.
Create a custom action within the MSI which gets installed first, then either write the values/user entries that you want into a file or registry. Within your final MSI read the values from registry/file and use it.
Here is an example of how you can read a value from the user and update the your app.config, this is not an apple to apple scenario, but this will guide you through it.
http://bensnose.blogspot.com/2013/03/more-custom-actions-with-wix.html
Disclaimer: I havent tried out what is mentioned in this blog post, but I have done things very similar and found that it has good explanation, thats why I posted the link to it.
I have created a wix build, which does the following
1. Install the files in temporary location.
2. Then I call a custom Action to copy the files into a different location and does messaging of some of the config files.
3. Display a message to user that installation is complete.
4. and then Exit the MSI.
PROBLEM: The reference to the MSI exists in control panel add remove program.
How can I remove the reference of the project from add remove program?
Is it possible within the same WIX build?
What are the alternatives to achieve it?
Thanks,
M
Assuming that you want to prevent your application from being displayed in the Add or Remove Programs list of Control Panel.
Then you need to set property ARPSYSTEMCOMPONENT in to 1.
<Property Id="ARPSYSTEMCOMPONENT" Value="1" />
Read more about ARPSYSTEMCOMPONENT
And also if you want it to show into add or remove programs, but remove or modify functions disabled then use ARP ENTRY properties.
<Property Id="ARPNOMODIFY" Value="1" />
<Property Id="ARPNOREPAIR" Value="1" />
<Property Id="ARPNOREMOVE" Value="1" />
Refer for More Info: ARP ENTRY
And if you don't want your program to be uninstall using msiexec also you can add condition like
<Condition Message="Uninstall is not supported">REINSTALL or Not Installed</Condition>.
Uninstall using msiexec.exe /x will give pop-up saying uninstall is not supported and will quit.
I'm using an rtflicence standard bootstrapper to install dotnet before my poject msi in a chain.
I noticed that there's an 'options' button which displays an install location dialog and allows the user to change the default installation directory.
I need to either:
Prevent this options button from being displayed, or
Populate the install location with a default path, and pass this back to the installer should the user change it.
I read that it's possible to pass Burn variables to msipackages from bootstrapper but I haven't found any further details and would appreciate being pointed in the right direction.
Thanks
To go with option 1, you'd have to roll your own BootstrapperApplication and remove the options button from the menu.
Option two is significantly easier to implement. The bootstrapper uses a special Burn variable called InstallFolder to get and set what is in the text block on that view, which you can assign inside the Bundle element.
<Variable Name="InstallFolder" Type="string" Value="[ProgramFilesFolder]"/>
The constant ProgramFilesFolder will set the value of that text block when the program starts, and if the user browses to a different directory, it will be stored in that same variable. To pass it to the MSI, in your chain, you pass the InstallFolder using the MsiProperty tag (INSTALLLOCATION is the name of the property in your WiX project).
<MsiPackage Vital="yes" DisplayName="Your Name" Id="MsiId" SourceFile="path/to/file.msi">
<MsiProperty Name="INSTALLLOCATION" Value="[InstallFolder]" />
</MsiPackage>
I just discovered the SuppressOptionsUI option that addresses your Option 1 without rolling your own BootstrapperApplication:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle>
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense">
<bal:WixStandardBootstrapperApplication LicenseFile="..\eula.rtf" SuppressOptionsUI="yes"/>
</BootstrapperApplicationRef>
<Chain>
</Chain>
</Bundle>
</Wix>
I think you can try removing the options button by creating a theme. I haven't had to use themes myself but here are two related SO links that may get you pointed in that direction:
WiX bootstrapper theme file?
Theme for my WiX Installer