Why .NET Framework 2.0 language packs will not install correctly on Windows Vista
Michael Kaplan wrote a blog post a while back that described an algorithm for enumerating installed .NET Framework culture information on a computer. While I was away on vacation for the holidays, he posted a follow-up that explains why this algorithm won't work reliably on Windows Vista. The underlying issue is that the MSI-based .NET Framework 2.0 language packs will not install on Windows Vista.
Michael explained some of the reasoning for this in his blog post, but I wanted to explain in a bit more detail the setup logic that prevents the .NET Framework 2.0 language packs from installing as-is on Windows Vista and also provide some options for working around this if necessary on your systems.
How .NET Framework 2.0 language pack setup works behind the scenes
I previously explained a scenario where Visual Studio 2005 would fail to install on beta versions of the Windows Vista x64 edition. Partially to solve this scenario, and partially to prevent users from being able to install both the MSI-based redistributable and the Windows OS component for the .NET Framework 2.0, some registry values were added to the final release of Windows Vista.
These registry values are located at HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v2.0.50727\<LCID>, where <LCID> is one of the following 4-digit language codes for .NET Framework 2.0 language packs on a Windows Vista system:
1028, 1029, 1030, 1031, 1032, 1035, 1036, 1038, 1040, 1041, 1042, 1043, 1044, 1045, 1046, 1049, 1053, 1055, 2052, 2070, 3076 and 3082
Each of these registry sub-keys has 3 values named Install, MSI and OCM. All 3 of these values are set to 1 for each LCID in the above list.
The MSI-based .NET Framework 2.0 language pack installer packages contain logic in the setup bootstrapper that prevent the user from installing them if it detects that the language pack is already installed as an OS component. The algorithm it uses to determine whether or not the language pack is installed as an OS component is the following:
- Look in the [Setup] section of the file install.ini that is a part of the langpack.exe self-extracting setup package
- Retrieve the value of the ProductRegKey item to determine what registry key to look at
- Retrieve the value of the ProductRegValue item to determine what registry value to look at
- Check to see if that key/value exists and is equal to 1, and if so, block installation and tell the user that the product is already installed as part of the OS
.NET Framework 2.0 language pack setup behavior on Windows Vista
As a result of all of the above, users cannot install the .NET Framework 2.0 language packs on Windows Vista. The officially supported way to install .NET Framework 2.0 language packs is to install the corresponding Windows Vista MUI language pack (which also includes .NET Framework 2.0 language resources since the .NET Framework 2.0 is an OS component on Windows Vista). However, Windows Vista licensing terms only support installing multiple language packs on the same system for a couple of editions - Ultimate and Enterprise. The Guide to Windows Vista Multilingual User Interface has more information about language packs on Windows Vista if you are interested in reading more details about this scenario.
Because it is possible to install the .NET Framework 2.0 language packs as an OS component on Windows Vista, it was deemed necessary to prevent the MSI-based language packs from also installing in order to avoid interaction issues. The OS installation technology is (unfortunately) different than the Windows Installer (MSI) application installation technology, and therefore so is the system of servicing the files installed by each technology. Without being able to reliably determine which technology installed the file, it would be very difficult do deliver updates and hotfixes for these files and difficult to support repair and uninstall scenarios. This led to the decision to not allow the MSI-based language packs to install.
However, in order to be compatible with multi-lingual applications that include the MSI-based language packs as a part of their setup, the return codes for the MSI-based language packs will indicate success if the user tries to install them on Windows Vista. This should allow 3rd party installers to complete successfully in most cases.
In these cases, the language pack setups will return success, but the files will not actually exist on Windows Vista. As a result, some .NET Framework error messages and other strings will not display in the language of the language packs because the files themselves will not end up getting installed on the user's system. Also, the algorithm that Michael Kaplan previously described will report (correctly) that the language pack satellite assemblies are not installed, which is inconsistent with the successful return code that language pack setups return.
A customer reported a bug describing this issue on the Product Feedback web site at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=248617.
How to install MSI-based language packs on Windows Vista
In some cases, it is not necessary to install .NET Framework 2.0 language packs even if you are deploying a multi-lingual .NET Framework 2.0 application. This is because the strings included as part of the language pack are only used to display errors that are not handled within the language resources of the application itself. Therefore, errors that developers want to display correctly can be handled in the application code and included in the application's language resources.
However, if you have a scenario where you need to install more than one .NET Framework 2.0 language pack on Windows Vista and you do not have access to the Ultimate or Enterprise editions, you can use the following steps to unblock installation. Before doing this, please take note of the following important caveats:
- This installation method is not officially supported by Microsoft, so if you undertake these steps, it is at your own risk
- Hotfixes that specifically target the .NET Framework 2.0 language packs are not very likely, but in the case that Microsoft releases a hotfix for any of the language packs, they will most likely not install correctly on Windows Vista for language packs installed in this way. This means you will likely have to manually install hotfix files onto systems that use this installation method.
- If you install the language packs in this way on Windows Vista Ultimate or Enterprise edition and then decide to install the OS language pack, there is a chance that the MSI-based language pack will have interaction issues with the OS language pack. I strongly advise uninstalling the MSI-based language pack before installing any OS language packs to avoid any interaction issues like this.
You can use the following steps to install MSI-based .NET Framework 2.0 language packs on Windows Vista:
- Download the .NET Framework 2.0 language pack that you want to install by going to https://www.microsoft.com/downloads/details.aspx?familyid=39C8B63B-F64B-4B68-A774-B64ED0C32AE7&displaylang=en, selecting the desired language in the dropdown list box and clicking Download
- Extract the contents of the langpack.exe file downloaded in step 1 by running langpack.exe /t:%temp% /c
- Open the file %temp%\install.ini in a text editor such as notepad
- In the [Setup] section, look at the ProductRegKey and ProductRegValue items
- Using regedit, rename the registry value referred to by the ProductRegKey and ProductRegValue items in install.ini. In most (but not all) cases, this value will be HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727\<LCID>\OCM.
- Run the file %temp%\install.exe to install the language pack
- Rename the registry value that was changed in step 5 above back to the initial value
Note: you can change the %temp% folder to some other location when extracting the contents of langpack.exe above.
There is a bug in the installation logic for the .NET Framework 2.0 Arabic language pack that was reported at https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=248621. However, if you use the installation instructions described above instead of the ones described in the above bug reports, they will work equally well for all language packs and you will not need to perform any special steps to workaround this Arabic installation issue.
What to do if the language pack setup logic is problematic for your scenarios
I wanted to add one final comment here - I think that the packaging model for the .NET Framework 2.0 language packs is less than ideal on Windows Vista. However, given the variables that the teams had to work with and the need to complete work on Windows Vista, the decision was made to not allow the MSI-based language packs to install on Windows Vista and the behavior currently seen when trying to install the language packs is by design. If you have scenarios where this design does not work well, please report feedback on the .NET Framework Product Feedback site so that the teams will have more data to use when evaluating future changes to this packaging model. Based on my past experience, the data from this site is taken very seriously by the teams here at Microsoft, so please do not think that this information goes into a black hole or is not ever looked at by product teams.
<update date="1/2/2007"> Modified the wording where I describe Michael Kaplan's .NET Framework language resource enumeration algorithm. Previously, I stated that his algorithm would not work on Windows Vista. The algorithm itself works fine, but it returns a result that is not consistent with the return code from language pack setup. In this case, the language pack setup return code is the thing that is incorrect - the language resources are not actually installed on the system, but setup "lies" and reports that it installed successfully to try to help avoid application compatibility issues for applications that include the language packs as part of their setup processes. </update>