About Windows Installer, the .NET Framework, and Visual Studio.
Language support in Windows Installer can be confusing until you understand how Windows Installer queries for and uses languages. Some wonder why Windows Installer packages have two different places to set the language. Some wonder why, for example, localized packages install using a different language than the user's default UI language. Some of these answers are in the Windows Installer SDK documentation, while some is not. Described in this post is how languages are used from before the package is opened to what happens during installation.
In general, Windows Installer looks for resources in the following order:
Windows Installer installation packages – both .msi and .msp files – are not executables and must be processed. Until that file can even be opened, Windows Installer queries for the user's default UI language using GetUserDefaultUILanguage() on platform that support this function (Windows 2000 and newer NT-based platforms), falling back on GetUserDefaultLangID(). If this should fail for any reason or Windows Installer is running entirely in the SYSTEM context, GetSystemDefaultLangID() is used. With every try, resources that are not available for a specific locale (ex: "en-US", or 1033) cause Windows Installer to lookup resources using a neutral locale (ex: "en", or 9). Messages displayed before the package is loaded would include error messages for errors like ERROR_INSTALL_SERVICE_FAILURE (1601), ERROR_INSTALL_PACKAGE_OPEN_FAILED (1619), etc.
Once the package is initially opened, Windows Installer uses the language of the product listed in the Template summary property, PID_TEMPLATE. If multiple languages are listed – which is really only valid for .msm files, or merge modules – the first language listed is used. A 0 for this field or leaving it empty indicates that the package is a neutral language package, and Windows Installer will search for resources in the order listed above, starting with the user's language.
The first language listed in PID_TEMPLATE is also registered for the product, which means this is the value returned from MsiGetProductInfo(). MsiGetLanguage() also returns this value when passed a product handle. INSTALLLOGMODE_COMMONDATA messages sent to UI handlers use this language until the ProductLanguage property can be read or if that property is not present. Most importantly when building transforms or patches, the first language listed in PID_TEMPLATE is the language used for transform validation.
When the package is opened and the ProductLanguage property can be read, this language is used for message lookup for INSTALLLOGMODE_COMMONDATA messages, ActionText, and Error messages, if available. If the ActionText or Error tables are empty or don't contain a record for a particular action or error, Windows Installer uses the ProductLanguage to lookup messages in the search order listed previously. ProductLanguage would be the requested languages in this case.
On Vista, the ProductLanguage property is also used to dictate the language used for the UAC prompt, as well as information recorded in the event log and during system restore processing.
It is highly recommended that the language specified in the PID_TEMPLATE property and the ProductLanguage property match, or UI will be inconsistent.
Remembering the search order and considering what's available during different phases of Windows Installer execution can help identify how Windows Installer selects a language. If a package isn't available, Windows Installer has only the preferences set for the user or system. After a package is loaded but before the data structures can be read, Windows Installer uses the PID_TEMPLATE property in the summary information stream. Once the package is fully loaded the ProductLanguage property in the Property table can be used.
I thank Carolyn Napier, the Windows Installer team's development lead, for a big help in identifying some of the more obscure uses of which language properties that weren't documented or easily discoverable.
PingBack from http://www.computer-juice.com/forums/f48/error_install_package_open_failed-1619-a-23534/#post111344
I have an msi which is installed on win7 japanese platform, it displays a dialog which says "the system requires reboot after installation" in english. I changed the ProductLanguage property to 0 (before it was 1033). now during installation it displays the dialog in japanese language which meets my requirement but the template summary is still set to "1033;1041;2052". As per the article the ProductLanguage Property and Template_summary should be same. but in my case both are not same but its still working. Please suggest your opinion on this.
I was experimenting with the Languages attribute in Wix.
These are my findings:
-The Language attribute for the <Product> element determines the language that would be displayed in the progress bar and the error messages.
-The Language attribute for the <Package> element determines the language that gets used for the strings in the user interface and the buttons on the UI.
However, as i was reading your article,it completely confused me.
Couple of points:
1)In the above article, the author refers to PID_TEMPLATE(Template summary property) and says that it cannot use multiple languages. However, the documentation for Template Summary property says that multiple languages can be specified..
Further, he goes on to say that:
The first language listed in PID_TEMPLATE is also registered for the product, which means this is the value returned from MsiGetProductInfo(). MsiGetLanguage() also returns this value when passed a product handle.
Well i thought that the language attribute of the <Product> element gets registered for the product.
2)He further goes on to say that once the package is loaded, the ProductLanguage property is used for ActionText and ErrorMessages.
Well this is what i found in my experiements too, as the ProductLanguage property corresponds to the Language attribute for the <Product> element.
3)After a package is loaded but before the data structures can be read, Windows Installer uses the PID_TEMPLATE property in the summary information stream.
What phase of the installation is being referred to here?
-What does the author mean when he talks about PID_TEMPLATE? I am assuming that he is referring to the Languages attribute under <Package> element.
Any assistance would be very much appreciated.
Yes, the Package/@Language corresponds to the PID_TEMPLATE summary information.
Multiple languages are only supported for installation databases, but even as you found, practically useless for MSIs. They are only practically useful - and, therefore, only supported that way by WiX - for MSMs.