ICE03: Invalid Language Id. Solution without suppressing the retrieval of file information - wix

I have a Setup Project for WiX v3 in Visual Studio. When building I am getting the same error on two different files. I would like to avoid this error without suppressing the retrieval of file information. Ideally I want to solve this with changes to the xml to make it easier for my coworkers to make changes in the future.
ICE03: Invalid Language Id; Table: File, Column: Language
The problem with both files is that they have a language of 1252. Both are dll's from the mid 90's and published by someone else.
I have read that I can pass -sh to light.exe to suppress retrieval of file information. Or I can skip ICE03 when running light. I would rather not do that since I could miss other errors.
I have tried setting the language to 0 on the product. I have also tried setting the default language on the files themselves. There is more language related markup I tried but I didn't have any luck.
In the xml have included only the two files that are causing the error. As well as any supporting xml incase it is of interest.
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="MyProject" Language="1033" Version="1.0.0.0" Manufacturer="My Company" UpgradeCode="8156a540-97a9-4d3d-b345-9a6d8b833be9">
<Package InstallerVersion="200" InstallScope="perMachine" Platform="x86"/>
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate/>
<Property Id="INSTALLLOCATION" Value="C:\"/>
<SetDirectory Action="SetInstallDir" Id="INSTALLDIR" Value="[INSTALLLOCATION]"/>
<Feature Id="ProductFeature" Title="MyProject" >
<ComponentGroupRef Id="Run32Components" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="INSTALLDIR">
<Directory Id="RRSDIR" Name="RRS">
<Directory Id="RUN32DIR" Name="RUN32">
</Directory>
</Directory>
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="Run32Components" Directory="RUN32DIR">
<Component Id="PICS2.DLL_Component" Guid="{855DFCC8-50B1-4213-81BA-68878EB31486}">
<File Id="PICS2.dll" Name="PICS.dll" Source="RUN32\PICS2.DLL" />
</Component>
<Component Id="PICSCCRW.DLL_Component" Guid="{A1859D86-1556-497D-8254-118823BF92FB}">
<File Id="PICSCCRW.DLL" Name="PICSCCRW.DLL" Source="RUN32\PICSCCRW.DLL"/>
</Component>
</ComponentGroup>
</Fragment>
</Wix>

16-Bit Windows Modules: These two DLL files appear to be 16-bit Windows modules, and as such the language set seems to be a code page
and not a language code at all. I will forward to the WiX guys. Just ignore the whole problem I would say, should be fine - barring the madness of installing 16-bit components :-).
Leaving the below for future reference - just in case. Real answer
ends here.
Preliminary Links: While at it, let me lob you some links to related, pre-existing answers. I assume you have found at least one of them already:
wix installer ice03 Invalid Language Id.
Wix toolset license agreement multi-languages issue
As seen in the latter answer you might have a session toying with code pages for the whole package. There are probably better fixes than that though.
Ad-Hoc Sample: Always impossible to add something that you haven't tested and have it work, but just so it is clearer without compiler variables, LCIDs set in Product and Package elements:
<Product Id="*" Name="MyApp" Language="1041" Version="1.0.0"
Manufacturer="MyCompany" UpgradeCode="PUT-GUID-HERE">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine"
Languages="1041" SummaryCodepage="932" />
LCID:
LCID
VbsEdit LCID Chart
CodePage:
Creating a Database with a Neutral Code Page
https://en.wikipedia.org/wiki/Code_page
https://en.wikipedia.org/wiki/Windows_code_page
Other Links:
wix incorrect font used during installation on Windows XP

Related

Simple Default Wix MSIX Project Throws a FgExcludeDarwinFeatures Error On Build

I'm testing out the MSIX features of the WiX framework. When I attempt to build I receive the following error:
light.exe(0,0): error LGHT0221: The definition for the
'FgExcludeDarwinFeatures' table's 'Feature_' column is a foreign key
relationship to the 'Feature' table's column number 1. The
modularization types of the two column definitions differ: one is
Column and the other is None. Change one of the modularization types
so that they match.
My setup:
Followed installation instructions from: https://www.firegiant.com/wix/wep-documentation/getting-started
Created a default wix setup project in visual studio 2019. Included FgMsixExtension.wixext.dll, included the fgmsix.xsd property on Wix element.
I'm running toolset v3.11.2.4516 (latest). Expansion Pack v3.11.476 - 2020-12-22 (latest)
Project compiles fine without the MSIX line, and the inclusion of the FgMsixExtension.wixext
Any ideas what I am missing?
Also does anyone have a working WiX msix example I can also compare to?
Just in case it is needed, here is a very quick edit of the default setup project from a wix template:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:fga="http://www.firegiant.com/schemas/v3/wxs/fgmsix.xsd">
<Product Id="*" Name="SetupProject3" Language="1033" Version="1.0.0.0" Manufacturer="test1" UpgradeCode="77c4b832-ed73-4ba2-825c-7eee7837a8f4">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<fga:Msix Id="testy" Publisher="CN=test1" Target="desktop" />
<!--<fga:Application Id="MyApp" ExecutableFile="prodFile" />-->
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<Media Id="1" Cabinet="test.cab" EmbedCab="yes" />
<Feature Id="ProductFeature" Title="SetupProject3" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="SetupProject3" />
</Directory>
</Directory>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<Component Id="ProductComponent">
<File Id="prodFile" Source="C:\Program Files (x86)\WiX Toolset v3.11\bin\FireGiant.LicensingTool.exe" />
</Component>
</ComponentGroup>
</Product>
</Wix>
Just finished a conversation with FireGiant Support. This was due to a bug:
The dev team published the fix in v3.11.479. This should solve the issue you faced.
Let us know if you have any other questions or problems.
Happy packaging!
-- FireGiant Support
v3.11.479 released 01/15/2021

How to avoid having two versions of a product installed with Windows Installer / MSI?

I have written and am maintaining a number of Wix installation source files which I use to build MSI files for distribution of my application.
I have not explicitly programmed for any kind of upgrading, updating, reinstallation or anything of the kind -- there is a single feature that consists of a number of components with stable GUIDs and I have observed that at least a clean installation does what I expect it to.
However, I (and anyone in possession of the MSI files I distribute) may seemingly install distinct versions of my application side-by-side using their respective (distinct) MSI files. Which isn't a problem in itself, except that I obviously use the same folder as installation target -- "%ProgramFiles(x86)%\Foobar" -- to install the application (version regardless) in. Meaning that in effect there is always ever one version that ends up being installed.
I would argue that Windows Installer behaves correctly in so far that it updates files from whichever MSI package it installed last. One interesting side-effect of this is that if the last MSI was of earlier version, the files in the application folders would be overwritten with the copies from that earlier version.
But none of that seems to be the actual problem to me. I want to fix the disparity between what is actually installed (a single application version) and what Windows tracks as installed -- in my case two records of two distinct application versions.
Since I install the application in a folder that doesn't depend on the version being installed, tracking multiple application versions by Windows is a mistake.
So I guess my question is, how do I fix this so that only one version is shown (reflecting reality) or what's the idiomatic approach in these kind of cases? I deliberately did not overspecify my Wix source code, hoping in return that Windows Installer would use some built-in intelligence to figure everything out on its own. But I may need to add some explicit upgrade or uninstall-previous-version-first instructions, I suppose.
My minified Wix source code (file "foobar.wxs") would look like this:
<?xml version="1.0" encoding="utf-8" ?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi" xmlns:util="http://schemas.microsoft.com/wix/UtilExtension">
<Product Name="Foobar" Manufacturer="ACME Inc." Id="*" UpgradeCode="ae9a7d6d-6c2d-446a-97d9-9dbe829d2ea8" Language="1033" Codepage="1252" Version="!(wix.PRODUCT_VERSION)">
<Package Id="*" Languages="1033" SummaryCodepage="1252" Compressed="yes" InstallerVersion="200" />
<Icon Id="foobar" SourceFile="!(wix.APPPATH)/foobar.ico" />
<Property Id="ARPPRODUCTICON" Value="foobar" />
<Property Id="ARPCOMMENTS" Value="Gives you full foobar powers" />
<MediaTemplate EmbedCab="yes" CompressionLevel="high" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="DesktopFolder" />
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLDIR" Name="Foobar" FileSource="!(wix.APPPATH)">
<Component>
<File Id="foobar.exe" Name="foobar.exe" />
</Component>
<!-- There are other components like above (assets) -->
</Directory>
</Directory>
<Directory Id="ProgramMenuFolder">
<Directory Id="foobar_menu" Name="Foobar">
<Component Id="foobar_shortcut" Guid="e80a6b95-a145-453a-b327-65a977e741fe">
<Shortcut Icon="foobar" Id="foobar_shortcut" Name="Foobar" Target="[foobar]foobar.exe" />
<Shortcut Directory="DesktopFolder" Icon="foobar" Id="foobar_desktop_shortcut" Name="Foobar" Target="[foobar]foobar.exe" />
<RegistryValue KeyPath="yes" Root="HKMU" Key="Software\[Manufacturer]\[ProductName]" Type="string" Value="" />
<RemoveFolder Id="remove_foobar_menu" On="uninstall" />
</Component>
</Directory>
</Directory>
<Directory Id="CommonAppDataFolder">
<Directory Id="app_data_foobar" Name="foobar">
<Component Guid="" Id="app_data_config_folder">
<CreateFolder />
</Component>
<Component Guid="" Id="app_data_config_folder_log_file">
<File Name="foobar.log" Source="foobar.log.template">
<!-- Add write access permission to the log file to members of "Users" group. -->
<!-- PermissionEx Sddl="D:AR(A;;GWGR;;;BU)" / -->
<!-- Bug with Windows Installer, can't use PermissionEx/MsiLockPermissionsEx table. See https://stackoverflow.com/questions/55145282/how-to-include-inherited-permissions-when-specifying-permissions-for-a-file-inst -->
<util:PermissionEx Append="yes" GenericWrite="yes" User="Users" />
</File>
</Component>
</Directory>
</Directory>
</Directory>
<Feature Id="foobar">
<ComponentGroupRef Id="foobar" />
<ComponentRef Id="foobar_shortcut" />
<ComponentRef Id="app_data_config_folder" />
<ComponentRef Id="app_data_config_folder_log_file" />
</Feature>
</Product>
</Wix>
I am compiling the object file with the following Windows Command Prompt line:
candle.exe -ext WixUtilExtension -out %TEMP% foobar.wxs
And then generating the MSI file with:
light.exe -ext WixUtilExtension -spdb "-dAPPPATH=%apppath%" "-dPRODUCT_VERSION=%version%" -out %TEMP%\foobar-%version%.msi %TEMP%\foobar.wixobj
(using Wix 3.11.1.2318)
Upgrade Code: As long as you have set an upgrade code (which identifies a bunch of related products) you can use a major upgrade element to indicate products that are to be uninstalled as part of a new MSI's installation.
MajorUpgrade Element: Just inject a MajorUpgrade element for default treatment of major upgrades into your existing WiX source. It is a sort of "magic element" doing a lot for you making a number of (usually good) assumptions. There are older and more flexible ways to do it - if you need more detailed control (for legacy purposes usually - auto-magic does not cover all bases):
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
The above is the standard use for all WiX files created in Visual Studio.
Note: I will try to tune up this answer shortly with more links, but give that a go first?
First link: Using Visual Studio to make WiX files. The Hello WiX and Visual Studio-type of scenario.
Major Upgrade Suggested Reading: A few things to know about major upgrades. All WiX markup essentially revolves around the compiled MSI's Upgrade table. It is there that major upgrade logic is configured. Custom actions could also affect things, and a few other things such as launch conditions perhaps.
WiX Documentation: How To: Implement a Major Upgrade In Your Installer
Major Upgrade - Common Problems: WIX does not uninstall older version
Major Upgrade - Manual Configuration: Adding entries to MSI UpgradeTable to remove related products (using old-style Upgrade elements)
Further:
Major Upgrades - How-To & Concept: Doing Major Upgrade in Wix creates 2 entries in Add/Remove Programs

How to make certain a Wix installer will override (upgrade) an older version and won't allow a downgrade

I've tried most of the answers on the topic in this forum and other forums, but I still have this problem.
I want to update a bundle version and when I build and install the installer, it should upgrade a previous installation and not create two records in "Programs and Files".
I'm using the following code in Product.wxs.
<Product Id="*" Name="SetupProject1" Language="1033" Version="1.0.0.0" Manufacturer="miro" UpgradeCode="5ba49b49-25c4-47c0-82da-12bf5310af58">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade AllowDowngrades="no" AllowSameVersionUpgrades="yes" IgnoreRemoveFailure="no" DowngradeErrorMessage="loc.NewerVersionInstalled" Schedule="afterInstallInitialize"/>
<MediaTemplate />
<Feature Id="ProductFeature" Title="SetupProject1" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="SetupProject1" />
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<Component Id="ProductComponent">
<File Id="file_Exefile" Source="..\ConsoleApplication1\bin\Debug\ConsoleApplication1.exe">
</File>
</Component>
</ComponentGroup>
</Fragment>
I am even considering writing my own update logic based on the Installer Processes and their ProductVersion properties, but there are too many cases to consider.
Can you tell me what is wrong with this Product.wxs ,so I can fix it.
Thanks.
Best regards,
Evgeni Dyulgerov
There are several things that could be preventing a major upgrade. You appear to have the correct MajorUpgrade logic, but:
It would be better if you incremented your product version in the first three fields, that's more normal for a major upgrade.
It's not obvious that your current UpgradeCode is the same as the older product's, so check that it is.
If the previous product's install scope was perUser the major upgrade will not work because cross-context major upgrades aren't allowed by Windows Installer.
Do the install taking a verbose log and look at all occurrences of FindRelatedProducts. There will be more than one, but see if the one in the upgrade install finds a previously installed product.
You have to add an upgrade section to your product section.
<Upgrade Id='5ba49b49-25c4-47c0-82da-12bf5310af58'>
<UpgradeVersion OnlyDetect='no' Property='ISUPGRADE'
Minimum='0.0' IncludeMinimum='yes'
Maximum='1.0.0.0' IncludeMaximum='no' />
</Upgrade>
Checkout Upgrades and Modularization on Firegiant
Also the WiX Documentation chm (in your Start Menu) is very helpful.

WiX Bootstrapper

I am trying to create an installer for a simple .NET WPF C# app. I am using VS 2013, and WiX 3.10.2. Following the steps in the Wix Tutotial/ .NET/ Bootstrapping I have created a Boostrap.exe which chains .NET web installer and the app Setup.msi.
EDIT: My goal is to understand how to configure the WiX Bootstrap and Setup projects for small updates, minor upgrades, and major upgrades scenarios.
Out of the box, everything seems to work nice when I run a fresh install. However, when I run a fresh built Bootstrap.exe over an already existing installation a duplicate entry appears in the Apps & features and no file is changed in the app target location - contrary to the expectation that the same entry should remain in the Apps & features and the target location should be updated. EDIT: Looks like there may not be a way to change REINSTALLMODE?
If I add a Product Id and then change the version of the Setup (minor upgrade), the Bootstrap fails with User cancelled installation? The log file shows "Error 0x80070642: Failed to perform minor upgrade of MSI package." EDIT: Inside the MSI log a SecureRepair fails with error code 39439E438 (?) probably because the stored hash value does not match the current... but that should be expected in a minor upgrade MSI, right?
Are there recommended configurations between the Boostrapper and Setup WiX projects such that the small update, minor upgrade, and major upgrade use cases can be handled properly, or does the WiX Bootstrapper support ONLY major upgrades?
I will continue to investigate and I'll post updates to my findings;
Any hints are greatly appreciated,
Thanks!
Here are the source files which I barely changed from the WiX wizard generated code:
--- Product.wxs ---
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="SetupProject1 1.0.0.0" Language="1033" Version="1.0.0.0" Manufacturer="Acme" UpgradeCode="4c8a8cbf-e3d0-410c-8a8d-7e67eb4e7ff7">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perUser" InstallPrivileges="limited" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate />
<Feature Id="ProductFeature" Title="SetupProject1" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="LocalAppDataFolder">
<Directory Id="AcmeFolder" Name="Acme">
<Directory Id="INSTALLFOLDER" Name="WpfApplication1" />
</Directory>
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<Component Id="ProductComponent" Guid="8CA0B70F-39DA-4B4B-9104-46C58E26FCF4">
<CreateFolder/>
<RemoveFolder Id="RemoveAcmeFolder" Directory="AcmeFolder" On="uninstall"/>
<RemoveFolder Id="RemoveINSTALLFOLDER" On="uninstall" />
<RegistryValue Root="HKCU" Key="Software\Acme\WpfApplication1" Name="Version" Type="string" Value="[ProductVersion]" KeyPath="yes" />
<File Source="$(var.WpfApplication1.TargetPath)" KeyPath="no" />
</Component>
</ComponentGroup>
</Fragment>
--- Bundle.wxs ---
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
<Bundle Name="Bootstrapper1 1.0.0.0" Version="1.0.0.0" Manufacturer="Acme" UpgradeCode="e1092cbb-9134-42fc-a9f2-652f95f361fd">
<BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLicense" />
<Chain>
<MsiPackage Name="Acme Setup" SourceFile="$(var.SetupProject1.TargetPath)" Vital="yes" />
</Chain>
</Bundle>
If you change your executables, increase their version numbers. Windows Installer assumes files with the same versions are the same.
To upgrade an .msi package, increase its version number either as part of a major upgrade (typical) or minor upgrade.
To upgrade a bundle, increase its version number. By default, Burn keeps bundles with the same version installed.

After minimize/restore the EULA window the information disappeared

I'm using ScrollableText control to display EULA and everything works fine except the following scenario:
When EULA dialog is displayed select some word(s) then minimize the EULA window. After restoring the window whole license information disappeared. But after selecting some area in the control the EULA text is appears.
Could somebody help me to understand the root cause of the problem.
I have tried it with 3.0.5419.0 build on WindowsXP SP3 and Windows Installer 4.5 and have the same problem.
The WIX source is following:
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<?define ProductName="WixProject"?>
<?define ProductVersion="1.0.1"?>
<?define Manufacturer="WixProject"?>
<?define Language="1033"?>
<?define ProductCode="{830E8896-AD07-4fbb-8828-4165D2C84887}"?>
<?define UpcradeCode="{BA074C59-1F12-4a95-8BD8-177E18234AB3}"?>
<Product Id='$(var.ProductCode)'
Version='$(var.ProductVersion)'
Name='$(var.ProductName)'
Language='$(var.Language)'
Manufacturer='$(var.Manufacturer)'
UpgradeCode='$(var.UpcradeCode)'>
<Package InstallerVersion="200" Compressed="yes" />
<Upgrade Id='$(var.UpcradeCode)'>
<UpgradeVersion OnlyDetect="no" IncludeMaximum="no" Property="OLD_VERSION_FOUND" Maximum='$(var.ProductVersion)' />
</Upgrade>
<Media Id="1" Cabinet="media1.cab" EmbedCab="yes" />
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLLOCATION" Name="WixProject1">
<Component Id="ReadMeC" Guid="{3DC5A180-EC42-4466-8E4B-1BA37BFF189C}" SharedDllRefCount="yes" Win64="no">
<File Id="ReadMeF" Name="ReadMe.txt" Source="ReadMe.txt" Vital="yes" />
</Component>
</Directory>
</Directory>
</Directory>
<InstallExecuteSequence>
<FindRelatedProducts Sequence="200" />
<RemoveExistingProducts After='InstallFinalize' />
</InstallExecuteSequence>
<Feature Id="ProductFeature" Title="WixProject1" Level="1">
<ComponentRef Id="ReadMeC" />
</Feature>
<UIRef Id="WixUI_Minimal" />
</Product>
</Wix>
This is the very simple WIX file which installs only one file and uses WixUI_Minimal UI.
Even for this installer I can see the same problem.
Thanks.
The ScrollableText control is quite limited (as well as MSI UI in general). It's hard for me to point out the exact reason of such behavior, but probably one of Rob's suggestions helps (for instance, re-save your license.rtf in WordPad and try again).
It would also be interesting to know what exactly helped (when you manage to dig it out). :-)
All of my InstallShield installers don't even the minimize button enabled and I've never missed it. My WiX installers have minimize capabilities but I haven't reproduced your problem. What version of MSI do you have installed? Can you repro this on different machines with different versions?
I can reproduce this behavior using WiX's own installer. I guess I've just never tried to select some text then minimize the installer before. This is clearly a defect in MSI's internal UI and there isn't going to be anything you can do about it other then not enable the Minimize button like InstallShield does.
I have asked about this issue from the WIX developers and they say that the problem is in the Windows Installer RichEdit control.
For details please refer to the link below:
http://sourceforge.net/tracker/?func=detail&atid=642714&aid=3087369&group_id=105970