Wix creating multilanguage msi - wix

recently I'm working on creating a multilanguage wix msi package for my team. I searched the localization on Google and also on stackoverflow for quite some time and finally found something to follow:http://www.geektieguy.com/2010/03/13/create-a-multi-lingual-multi-language-msi-using-wix-and-custom-build-scripts/. Currently I just added 2 language support: english and simplified Chinese to check if this approach works for me. The main wxs front part is something like this:
<Product Id="B5CB3C6A-A8ED-4308-8ADE-17729FE1FB23" Name="MyProduct" Language="!(loc.LANG)" Codepage="UTF-8" Version="11.51.0027" Manufacturer="My Company" UpgradeCode="D42070C3-43CB-4E2B-9B96-2F8D84A6C8A8">
<Package InstallerVersion="200" Compressed="yes" Languages="1033,2052" InstallPrivileges="elevated" InstallScope="perMachine" />
And for the Language attribute of the Product I'm getting value from the localization wxl file, I've 2 files now, one is en-US.wxl, another is zh-CN.wxl,
in en-US.wxl: 1033
in zh-CN.wxl 2052
I also set the corresponding codepage in 2 wxl files, setting en-US codepage to 1252 and zh-CN to 936.
After building the project in VS, I got 2 msi, one in en-US folder and another in zh-CN folder, and I use the following commands to create the multilanguage msi:
cscript WiLangId.vbs zh-CN\MyProduct.msi Product 2052
Msitrans.exe -g en-US\MyProduct.msi zh-CN\MyProduct.msi zh-CN.mst
cscript WiSubStg.vbs en-US\MyProduct.msi zh-CN.mst 2052
cscript WiSubStg.vbs en-US\MyProduct.msi
And performing the commands above in cmd, I copied the final msi onto a Chinese win7 system to try, the problem is after I double clicking the msi to install, the first UI dialog is still in English but shortly it became Chinese, I'm sorry that I couldn't post the screenshot here because stackoverflow requires 10 reputations to be able to post images, but the words on the first Dialog I saw is "Preparing to install...." and a button on the bottom right "Cancel" and then after 2-3 seconds the UI became Chinese. Did anyone come up with this problem before?

Windows System restore point is created by default (if enabled system-wide) at the start of a MSI install. This system restore point seems to occur before locale transform and cause the behavior you observed.
You can disable it by setting MSIFASTINSTALL property to 1 or any value that includes it (e.g. 5 if you also want to reduce the amount of progress messages)
<Property Hidden="yes" Id="MSIFASTINSTALL" Value="1" />
For example in your .wxs file:
<?xml version="1.0" ?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util='http://schemas.microsoft.com/wix/UtilExtension'>
<Product Id="XXX" Name="XXX" Language='!(loc.LANG)' Codepage='0'
Version="XXX" Manufacturer="XXX"
UpgradeCode="XXX">
<Product Id="B5CB3C6A-A8ED-4308-8ADE-17729FE1FB23" Name="MyProduct" Language="!(loc.LANG)" Codepage="UTF-8" Version="11.51.0027" Manufacturer="My Company" UpgradeCode="D42070C3-43CB-4E2B-9B96-2F8D84A6C8A8">
<Package InstallerVersion="200" Compressed="yes" Languages="1033,2052" InstallPrivileges="elevated" InstallScope="perMachine" />
<!-- Disable System Restore point creation for this MSI (faster installation) -->
<Property Hidden="yes" Id="MSIFASTINSTALL" Value="1" />
<!-- Rest of your setup ... -->
</Product>
</Wix>
You can read about MSIFASTINSTALL on Microsoft Windows docs

Related

How to add a version number to the MSI filename with Wix

I should start by clarifying that I am a complete novice and unfamiliar with Wix, so I am relying on looking at other examples.
I have an installer that is working fine but the filename for the MSI needs to change.
My 'Product' section looks roughly like this:
<Product Id="*" Name="MyShellExtension" Language="1033" Version="1.0.0.0" Manufacturer="ACME Inc" UpgradeCode="???????-????-????-????-??????????">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate />
<Feature Id="ProductFeature" Title="MyShellExtension" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
<CustomActionRef Id="InstallShell"/>
</Product>
I found this posting but it's quite old and refers to a property called 'OutputName' that does not appear to be supported in Wix v3.11 which is what I have. WIX: Howto set the name of the msi output file dynamically
BTW when I installed "The latest version" of Wix I found that it had installed 3.11. I'm guessing it's because I'm running Visual Studio 2019 but if that's not the case and it's both possible and recommended to run more recent versions with VS 2019, please advise on where I might have gone wrong with the installation of Wix.
I found that I could right-click the project in Visual Studio and manually set the name there, which solved my initial problem, but I would like to add the version number of the component I'm installing to the filename.
I'm very new to all of this so it would be really helpful to have an example that I can paste in and modify.
The OutPut name property is in a .wixproj MSBuild file if your using VisualStudio / Votive / MSBuild. If your calling candle and light it's not used. You just pass in the parameter to set the output file name.

For Wix Toolset and UpgradeVersion tag is Property ever reset

We have the code below for our Product.wxs.
When the installer is run we can see afterward that BackupFiles custom action runs, but RestoreFiles does not run as shown in the log file:
"Skipping action: RestoreFiles (condition is false)"
Why does BackupFiles, with same condition, run and RestoreFiles not run?
Has the OLDVERSIONFOUND been changed?
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension"
xmlns:util="http://schemas.microsoft.com/wix/UtilExtension" >
<Product Id="*" Name="My Product" Language="1033" Version="0.0.0.0" Manufacturer="MyCompany"
UpgradeCode="{B55B9CB0-BA28-4BB3-834B-6075AD5D45E4}">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<UIRef Id="WixUI_ErrorProgressText" />
<!-- Specify UI -->
<Property Id="WIXUI_INSTALLDIR" Value="INSTALL_FOLDER" />
<Property Id="RestoreFiles" Value="INSTALL_FOLDER" />
<Upgrade Id="{B55B9CB0-BA28-4BB3-834B-6075AD5D45E4}">
<UpgradeVersion Minimum="1.0.0"
IncludeMinimum="yes"
OnlyDetect="no"
Maximum="0.0.0.0"
IncludeMaximum="no"
Property="OLDVERSIONFOUND" />
</Upgrade>
<InstallExecuteSequence>
<Custom Action="BackupFiles" After="InstallValidate" >OLDVERSIONFOUND</Custom>
<Custom Action="SetRestoreFiles" Before="RestoreFiles" />
<Custom Action="RestoreFiles" After="InstallFiles" >OLDVERSIONFOUND></Custom>
<RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>
</Wix>
Custom actions like these are not really recommended. They can be quite complicated to get right. See links towards the bottom on "settings preservation".
The short version is that settings files should never be installed, but created by the application from defaults or templates (then the setup will never interfere with them), or you can cloud all settings and retrieve on launch from a database. See here, section "cloud-style approaches".
Major Upgrades - Uninstall & Install: There is an important weirdness with major upgrades. You have to remember that you kick off the new installer, and then it will kick of the old installer's uninstall sequence as part of its own operation. Hence a major upgrade will run the uninstall sequence of your old setup and the install sequence of your new setup (potentially in different orders based on configuration of the major upgrade settings).
Counter-Intuitive Effects: This combined "install / uninstall" approach affects logic, conditioning, sequencing and also property values a great deal - and some changes are very counter-intuitive. In addition to two different versions running "at the same time" (or during the same operation), you must also keep in mind that the each installation / uninstallation sequence runs in two different modes: immediate (building execution script) and deferred (executing script executing). With poor conditioning the same custom action could run several times unexpectedly (including in the GUI sequence of the launched setup). Confusing. Debug using message boxes as described towards the bottom here.
Detailed Explanation: This complexity and the phenomenon of property values seemingly changing during installation is attempted explained in detail here: Run Wix Custom action only during uninstall and not during Major upgrade - please read that answer (dual source and all). I will look back later, it is too late for me to run tests tonight.
Throwing in some further links:
On settings preservation
Overview on settings preservation
"Property Debugger" - on how to test property values
"Property Debugger" - another version

Overriding text color in Wix

I am struggling to learn the wix toolset, and currently want to do something I should think would be very simple: change the color of the text displayed in the dialog boxes defined in the toolset.
I found a stackoverflow answer which said I could do this by customizing WixUI_Minimal (which is the dialog set I'm using), giving it a different ID, and referencing that ID in my main wix file. The customization would simply be to do this:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Fragment>
<UI Id="WixUI_Custom">
<TextStyle Id="WixUI_Font_Normal" FaceName="Tahoma" Size="8" />
<TextStyle Id="WixUI_Font_Bigger" FaceName="Tahoma" Size="12" />
<TextStyle Id="WixUI_Font_Title" FaceName="Tahoma" Size="9" Bold="yes" Red="255" />
And the reference in my main wxs file would be changed to:
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*"
Name="Lan History Manager"
Language="1033"
Version="0.5.0.0"
Manufacturer="Jump for Joy Software"
UpgradeCode="EB2D1FB0-A72E-466C-B12D-BCF84277E2DA">
<Package InstallerVersion="500"
Compressed="yes"
InstallScope="perMachine"
Manufacturer="Jump for Joy Software"
Description="Installs a tool for managing Windows File History backups to network shares"
Comments="(C) 2017 Mark A. Olbert all rights reserved"/>
<UIRef Id="WixUI_Custom"/>
Unfortunately, this does not work. When I compile the project, it generates dozens of errors, complaining about duplicate symbols, all of which appear to relate to other parts of the WixUI_Minimal "template" which I did not change.
I do not have any definition for WixUI_Minimal present in my project, and no references are made to WixUI_Minimal, so it shouldn't be dragging in the duplicate symbols.
But something obviously is.
Is there some other way of just changing the text color in the dialogs?
The WiXUI_* can only be extended and overridden in limited ways. To go where you want to go you pretty much have to take a copy of it and own it. Go to the WiX sources and find the files that define all of this in the UI Extension. Clone them into your project and eliminate the UI extension. Now you can go and change anything you want about it.
Alternatively you could also decide to go full silent in the MSI and do all your UI work in a burn bootstrapper theme and/or customer bootstrapper application.

InstallScope="perMachine" in wix makes no difference

Hi i need my application just to work in administator mode and all users mode.(ie)It should work in all the modes.
I have created setup in WIX and after surfing a lot i came to know that setting InstallScope="perMachine" in package makes our application work in all the modes. But i found that only it shows our application under Add\Remove programs in all logins(admin or other users).
(ie): I am able to work my application in administrator mode and if i logged in as any user then my application is not visible for working.Its just appears in Add\Remove programs.
My requirement is i need my application work in all the mode,administrator,logins,all users too.
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" ></Package>
Even i tried allUser option in InstallScopeDlg.
I need my application should work for all users including administrator too
In the Setup.wxs file add the following line
<Property Id="ALLUSERS" Value="1"></Property>
The file should look like :
<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*"
Name="programName"
Language="1033"
Version="1.0.0.0"
UpgradeCode="183CC369-D86F-43B3-99E7-A82A16335E52"
Manufacturer="CompanyName">
<Package Description="#Description"
Comments="Comments"
InstallerVersion="200"
Compressed="yes"/>
<!--
Source media for the installation.
Specifies a single cab file to be embedded in the installer's .msi.
-->
<Media Id="1" Cabinet="contents.cab" EmbedCab="yes" CompressionLevel="high"/>
<!-- Installation directory and files are defined in Files.wxs -->
<Directory Id="TARGETDIR" Name="SourceDir"/>
<Feature Id="Complete"
Title="programName"
Description="programName"
Level="1">
<ComponentRef Id="programNameFiles"/>
<ComponentRef Id="programNameRegEntries"/>
</Feature>
<!--
Using the Wix UI library
WixUI_InstallDir does not allow the user to choose
features but adds a dialog to let the user choose a
directory where the product will be installed
-->
<Property Id="WIXUI_INSTALLDIR">INSTALLDIR</Property>
<Property Id="ALLUSERS" Value="1"></Property>
<UIRef Id="WixUI_InstallDir"/>
</Product>
The Program Files folder cannot be updated by limited users. Just because you have a per machine install doesn't mean that Windows Installer will violate the security rules by allowing limited users to write there!
The most likely thing that is happening is that admins install successfully to Program Files because they have the privileges to do that. Limited users cannot write to Program Files, so the files get diverted, most likely to C:\ProgramData
When you say "the app is not working" for limited users I'll guess that it may be a security issue - it needs admin privilege because it tries to write/update restricted locations or registry entries. In other words your app will only work for limited users if it restricts its activities to those permitted to limited users. If the app is not working then debug it - it's impossible for anyone here to say why it's failing without a lot more information. That's an app issue, not an install issue.

How do you display the Product version in WiX-made MSI file properties?

How do I have the Product version displayed in the MSI file properties (as displayed by Windows Explorer)?
Our installer is created using WiX. All we see is the product GUID displayed as the Revision Number in the Details tab of the MSI file properties.
We'd like to have the product version (e.g.: 5.0.1.12345) so that the support team (and customers) can easily check the version of a given file.
Simply add the Comments attribute to the Package tag as below.
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" Comments="Version: 5.0.1.12345" />
There is no version property to be set. So as an alternative we are adding it to the comments attribute. So it can be seen in the properties of the msi.
I don't think that you can actually set a file version on MSI files in WIX. What we do is that we edit the description property of the Package.
<Package InstallerVersion="200" Description="Version: !(bind.FileVersion.filD6DA798364FCF1273EEE80AEF914C743)" InstallScope="perMachine" ...
And then we also make sure that the same version is used for the Product:
<Product Id="*" Name="Name" Language="1033" Version="!(bind.FileVersion.filD6DA798364FCF1273EEE80AEF914C743)" ...
The description is visible in your MSI file properties and so the version will be visible in the description. I hope that is what you want!