.NET Framework setup and language packs
The .NET Framework setup and packaging changed somewhat between v1.0 and v1.1 and there are further changes coming for v2.0 with respect to packaging of core bits and satellite language resources. I wanted to take a minute and provide an outline of the changes that have gone on as well as some of the reasoning behind them:
.NET Framework 1.0
1. There is a separate dotnetfx.exe package for each language version of the .NET Framework. Each package contains an MSI with a unique product code.
2. The English version contains the bits that provide the core product functionality as well as English language resources that are compiled into the core bits.
3. The non-English versions contained the core product bits (with English language resources) as well as a set of satellite resource DLLs that provide the appropriate non-English string resources.
4. Each language version of the .NET Framework SDK contained the equivalent of the matching language version of the .NET Framework redist package as part of the MSI.
5. Because of items 1 and 4, any time a Windows Installer patch is created for any of the bits that provide the core .NET Framework product functionality, separate logic has to be created to allow the patch to apply to all language versions of the .NET Framework redist and all language versions of the .NET Framework SDK
.NET Framework 1.1
1. There is a separate dotnetfx.exe package for each language version of the .NET Framework. Each package contains an MSI with the same product code and installs identical bits. The only difference between the dotnetfx.exe packages are the setup UI screens – they are translated into the appropriate language.
2. The dotnetfx.exe packages all contain the bits that provide the core product functionality as well as English language resources that are compiled into the core bits.
3. There is a separate langpack.exe for each non-English language version of the .NET Framework. These packages each install a set of satellite resource DLLs that provide the appropriate non-English string resources.
4. The .NET Framework SDK does not contain the .NET Framework redist. The SDK setup detects whether or not the .NET Framework redist is already installed on the machine, and if it is not found it blocks the user from installing the SDK until the redist is installed
.NET Framework 2.0
1. There is a single dotnetfx.exe package. It contains a single MSI that is marked as language-neutral and setup UI resource DLLs for all supported languages. It detects the user’s UI language settings and uses that to determine which language to display setup UI in.
2. The dotnetfx.exe package contains the bits that provide the core product functionality as well as English language resources that are compiled into the core bits.
3. There is a separate langpack.exe for each non-English language version of the .NET Framework. These packages each install a set of satellite resource DLLs that provide the appropriate non-English string resources.
4. The .NET Framework SDK does not contain the .NET Framework redist. The SDK setup detects whether or not the .NET Framework redist is already installed on the machine, and if it is not found it blocks the user from installing the SDK until the redist is installed
So as you can see from above, there has been a gradual evolution from separate language-specific versions of the .NET Framework to a single language-neutral core package and satellite language packs. The solution being delivered for .NET Framework 2.0 is what we had originally hoped to ship for .NET Framework 1.1 but the changes required to make the core setup package truly language neutral was too great to finish with high quality in the relatively short time in between shipping 1.0 and 1.1. We have noted some confusion about why there are multiple dotnetfx.exe packages available on the Microsoft download center for v1.1, and I often hear questions about how the bits each of them installs differ from one another. I feel like the solution for v2.0 is much cleaner and easier to understand.
Some advantages of this packaging solution are:
1. Setup developers only need to include one version of dotnetfx.exe for any scenario where their application requires the .NET Framework.
2. A single patch can be created for any fixes made to core .NET Framework binaries. This makes the testing matrix within Microsoft simpler and improves the turnaround time for delivering fixes.
Some disadvantages of this packaging solution are:
1. Setup developers need to include one or more langpack.exe files to create a multi-lingual managed application.
2. Installing the .NET Framework SDK requires a separate step to install the .NET Framework redist.
I would like to hear any feedback that anyone has about the packaging changes that have happened for the .NET Framework. Is it making things easier for setup developers? Or harder (or more confusing)? Do you have any suggestions for future versions? If you have any questions or comments about any of the above please post them on my blog or send me a direct email at aaronste (at) microsoft (dot) com.
