The .NET Framework 3.5 is packaged as a core package that includes language-neutral binaries and English resources, plus a series of language packs. The .NET Framework 3.5 setup has logic to detect the UI language of the OS it is being installed on, and to automatically chain in the installation of the appropriate language pack if one exists for that OS language. However, there is a potential issue related to language packs that can affect .NET Framework 3.5 installation on non-English systems. I’ve seen this issue reported by several customers and I want to try to explain what is happening behind the scenes and offer some options for working around this if you run into it on your system as well.
Description of the issue
As of the time that I’m writing this blog post, the .NET Framework 3.5 language packs have not yet been released for download. As a result, if you run .NET Framework 3.5 setup on a non-English OS, it will attempt to download the language pack setup in the language that matches the OS language, but since they are not yet released, it will instead download a place-holder file and that place-holder file will fail to install because it is not a valid language pack setup package. At the end of installation, the .NET Framework 3.5 setup UI will state that setup succeeded because setup treats language pack failures as warnings and not errors. However, you may also see a warning or error as a result of this failed language pack installation even though the overall .NET Framework 3.5 installation process returns success.
In addition, if you attempt to use instructions like the ones listed in this blog post to create a network or CD install point for the .NET Framework 3.5, and then you run setup from that install point on a non-English OS that does not have Internet connectivity, setup will detect that it needs to download a .NET Framework 3.5 language pack (because it will not be able to find it in a relative path next to the main setup executable). However, setup will fail to download the package due to the lack of Internet connectivity. After setup completes, it will report that the .NET Framework 3.5 installation is successful, but will also display an error dialog that is caused by the language pack download failure.
How to diagnose the issue
In the case where .NET Framework 3.5 setup does not have Internet connectivity but detects that it needs to download a language pack, the log file named %temp%\dd_dotnetfx35install.txt will show error messages that look like the following:
[12/01/07,11:11:11] Microsoft .NET Framework 3.5LP – ESN: Cannot access file: C:\Documents and Settings\user\Desktop\netfx35\wcu\dotNetFramework\dotnetfx35\x86\dotnetfx35langpack_x86es.exe
[12/01/07,11:11:11] Microsoft .NET Framework 3.5LP – ESN: dlmgr: CDownloadJobBITSImpl::GetState(): TransientError
[12/01/07,11:11:11] Microsoft .NET Framework 3.5LP – ESN: dlmgr: Transient Error
Context: 5 Error code: -2145386480 Description: There are currently no active network connections. Background Intelligent Transfer Service (BITS) will try again when an adapter is connected.
The above is an example log file obtained by attempting to run .NET Framework 3.5 on a Spanish OS after copying the setup package to the desktop and disconnecting the network cable.
How to workaround this issue
Option 1 – control language pack chaining behavior with a command line switch
If you would like to prevent .NET Framework 3.5 setup from attempting to chain in any language packs during installation on a non-English OS, you can run setup with the following command line switch:
This is the syntax that Visual Studio 2008 setup uses when it chains the .NET Framework 3.5 so that it can ensure that .NET Framework 3.5 setup will not need network connectivity in order to install successfully.
One note – the /lang switch will not have any effect if you already have the .NET Framework 3.5 installed on your system. It must be used during initial installation in order to cause it to skip downloading and installing any language packs.
Option 2 – download language packs and add them to your .NET Framework 3.5 layout
Alternatively, once the .NET Framework 3.5 language packs are released, you will be able to download their setup packages and place them in the dotNetFx35\x86, dotNetFx35\x64 and/or dotNetFx35\ia64 folder after following the instructions in this blog post to create an installable layout. Doing this will prevent the .NET Framework 3.5 setup from attempting to download the language packs from the Internet if it detects that it needs to install one of them because the OS being installed on is set to use non-English UI.