A bug was discovered recently in the x64 .NET Framework 2.0 language pack setups. This bug will cause attempts to install non-English, non-Japanese versions of Visual Studio 2005 on a non-matching language of x64 Windows Vista x64 to fail. In other words, attempting to install the French Visual Studio 2005 on Windows Vista x64 English will fail (for example), but installing the French Visual Studio 2005 on Windows Vista x64 French will succeed.
This bug will also cause the standalone x64 and ia64 .NET Framework 2.0 language packs (except for Japanese) to fail if you attempt to install them on a non-matching language version of x64 or ia64 Windows Vista. If you try to install one of the affected language packs, you will get an incorrect message stating that this product cannot be installed because the files are already a part of the OS.
Depending on how the setup package is implemented, this bug will likely also cause other products that include the x64 or ia64 .NET Framework 2.0 language packs (except for Japanese) to fail when installed on a non-matching x64 or ia64 Windows Vista OS language.
How to workaround this issue
If you are planning to install any non-English or non-Japanese edition of Visual Studio 2005 on any x64 build of Windows Vista where the OS language is not the same as the Visual Studio language, you can use the following steps to workaround this bug:
- Download this zip file and extract the registry file inside of it to your x64 Windows Vista system
- Right-click on the registry file and choose to add the contents to your registry
- When prompted for elevation, choose to allow the process to run
- After the registry values are added, re-run Visual Studio 2005 setup
After applying this registry file, Visual Studio 2005 setup will react as though the .NET Framework 2.0 language pack is already installed and skip trying to install it, which will allow setup to succeed on your system. You will be able to use Visual Studio 2005 and the IDE UI will be in the correct language, but there will be some error messages (such as compiler errors and warnings) that will not be able to be displayed in the Visual Studio language because the necessary .NET Framework 2.0 language pack files will not be installed.
When and how this bug will be fixed
This bug affects all publicly available builds of x64 and ia64 Windows Vista. A fix will be put in place by the time Windows Vista ships, but I don’t know exactly when yet. Part of the fix will be to make Windows Vista OS setup write the registry values listed in the registry file that I listed in the workaround above.
There is also some additional work that will need to be done as a part of this fix because this bug is a special case of a more general issue. Currently, the .NET Framework 2.0 language pack binaries are installed by non-English builds of Windows Vista and by Windows Vista language packs. Both of these are installed using the OS installation technology, whereas the redistributable versions of the .NET Framework 2.0 language packs are installed by Windows Installer MSI packages. If we allowed mixing and matching of install technologies, that could potentially lead to servicing problems and end user confusion.
I am going to provide more details about the fix in a separate future blog post once the exact fix is decided because it has the potential to impact non-English managed application deployment scenarios on Windows Vista.
Explanation of the root cause
There is some incorrect information in the install.ini file for all x64 and ia64 versions of the .NET Framework 2.0 language packs except for Japanese that causes this issue. If you extract one of the langpack.exe files for a non-Japanese x64 or ia64 .NET Framework 2.0 language pack, you will see the following towards the top of the install.ini file in the package:
ProductRegKey=SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727
The bug is that this product registry key value should look like the following:
ProductRegKey=SOFTWARE\Microsoft\NET Framework Setup\NDP\v2.0.50727\LCID
(where LCID is the 4-digit numerical value for the language in question – see this link for a complete list of these values)
The effect of this bug is that the language pack setup looks for the existence of a registry value created by the core .NET Framework 2.0 package instead of one created by the .NET Framework language pack to decide whether or not to block because the product is already installed as a part of the OS. All languages of Windows Vista will have the core .NET Framework 2.0 package installed, but not all of them will have the corresponding language version of the .NET Framework 2.0 language packs.
This is complicated by the fact that Visual Studio 2005 setup uses the correct registry value (with LCID as a part of the key name) when deciding whether or not it needs to skip trying to install the language pack. So you end up with a scenario where Visual Studio 2005 setup thinks it needs to install the language pack, but the language pack itself thinks it is already a part of the OS and returns error code 4123, which Visual Studio setup interprets as failure because it is not equal to 0 or 3010.
The workaround listed above adds registry values that causes Visual Studio 2005 to not attempt to install the language packs. It does not address the scenario where you try to run the .NET Framework 2.0 language pack setup directly. If you really need to do that, you will have to open the langpack.exe package, update the line listed above in install.ini and then run install.exe. However, the long-term fix for this issue will likely cause this workaround to not work as well so I would suggest avoiding doing this for now if possible. I will post more information when I know more about the long-term fix.
This problem only exists in install.ini for the x64 and ia64 versions of the .NET Framework 2.0 language packs, except for Japanese. The reason that the Japanese language pack did not have this install.ini bug is that Japanese was the first non-English language that the Visual Studio team worked on for Visual Studio 2005 and the .NET Framework 2.0, and the processes used to create it were then used for the remaining languages. This registry setting was added correctly for Japanese, but was not included in the template needed to correctly translate it into the other non-English languages. As a result, the English information (the registry key name without the LCID value included as part of it) was left in each of the non-Japanese language packs.