Package/@Languages in WiX 4

[avivanoff]

In WiX 3 there is Package/@Languages element to specify a list of language the MSI package supports. When using wix convert tool to upgrade to WiX4, this element just gets removed. How do you specify languages in WiX 4 project?

Also posted on StackOverflow.

[BMurri]

Short answer: Package/@language. A single package can only contain one language. However, if you are using any wixtoolset provided assets (such as the WixUI extension), there are better ways. Those better ways are better even if you are not using WixUI.

If you are using MSBuild (aka dotnet, Visual Studio), best practice is to use .wxl files, where you set your language, and if you include several, several packages will be created. Second best practice is to provide a list of cultures you are building (MSBuild property Cultures).

If not using MSBuild, provide the culture using the -culture parameter and wxl files using the -loc parameter to the wix tool. Repeat -loc as needed.

BTW, specifying the cultures to build from the command-line/through MSBuild was considered best-practice during v3, as well.

[avivanoff]

Not true. A single MSI package may contain multiple embedded transforms for different languages. Hence the summary information can contain multiple language id’s. We used to set it via Package/@Languages in WIX 3. I need a way to do the same in WIX 4.

[barnson]

To build a package with embedded language transforms, you have to use another tool and can modify the summary information stream at that time. Until/unless WiX supports such packages natively, it makes no sense to support multiple languages in a package.

[BradyJ9]

Except for the fact that it was supported in v3, and now v4 has dropped a crucial feature. Many installers that relied on this for localization are now broken in those languages without a hint of documentation explaining why or the workaround. That seems like an issue.

[jmairboeck]

It was "supported" in Wix v3 in a way that resulted in broken MSI packages without some post-processing (creating and embedding language transforms into the MSI). Otherwise the MSIs coming out of Wix would not be runnable.

Now, with v4, the post-processing needs to do an additional step, that is, adding the language ID to the summary information Template property, as shown in the link posted by @avivanoff. Afterwards, it works just as before. Additionally, the "intermediate" output MSIs created by Wix are also runnable as is.

I have created a small tool that integrates the functionality of the Windows Installer SDK scripts into a single executable that can be run as a post-build step. Maybe I should publish that somewhere ...

[BMurri]

To sum this all up: the supported, recommended way to do localized installers is to build each language installer, pick one to be the base, generate transforms from the base for all the others, then ship the base and all relevant transforms, and include the selected transform with the base MSI in the installation command-line. This almost asks for a bootstrapper to make sure the command line isn't messed up by the end customer. Then again, using a bootstrapper may mean that the need to localize the MSI completely goes away (which is my personal recommendation for everyone who can get away with it, which I'm pretty sure is almost everyone except certain people shipping exclusively B2B software with specific deployment needs involving MSI advertising, which I haven't seen in a contract for almost 2 decades, now).

The "trick" of embedding the transforms with very specific names and turning the summary information language setting into a language list was never documented nor supported by Microsoft, which is why it's not currently supported by WiX, and is the reason tests for it were never added to the Toolset, and is the reason that the v3 behavior is considered to be in error. It's true that this "trick" is "easier" than the recommended supported way, that it was discovered by someone reverse engineering installation packages released by a different department at Microsoft, and it's unlikely (though not impossible) that Microsoft will break that use case, all reasons many people choose to prepare their packages that way. However, if something does go wrong, Microsoft is not likely to promise to fix it either, without you spending a bunch of money on them.

Since added steps/tools have always been required above and beyond what has been included in the WiX Toolset to take advantage of that "trick", it shouldn't be a huge hurdle to migrate your build tooling to WiX v4 and still end up with the desired final result. You will simply have one additional step in your process to add.

Once again, there's no bug here in v4 (although it's obvious that there was one in v3). The invitation to request support for this specific use case in some future version of the Toolset was extended, so if that will be a benefit to you, please feel free to create an issue to request support for that use case end-to-end so that all the steps will be done by the Toolset for you. Since this is open source software, if you want to ensure that it'll be in some future version of the Toolset, feel free to include a pull request with tests, or hire someone to provide that PR, to go along with that issue (I know Firegiant sells support contracts, and I think they still offer connecting you to independent contractors). There's an entire community here that would help you with your PR if it's that important for you.

[jmairboeck]

I published our tool here, if anyone needs it: https://github.com/RISCSoftware/CreateEmbedLangTransform

[BMurri]

@avivanoff From the link you provided:

Merge Modules are the only packages that may have multiple languages. Only one language can be specified in a source installer database. For more information, see Multiple Language Merge Modules.

However, since you are already doing things that are not supported by Windows Installer (even though they wrote the code that makes it work), go ahead and use the sdk tools to do the job (aka msiinfo)