assemblies. If your custom .NET Framework Language Pack does not use the same key, ResourceManager will not match your language pack satellite assemblies with the fallback assemblies in the .NET Framework. Consequently, any such custom .NET Framework Language Pack will be ignored.
This has a knock on effect if you use ClickOnce to deploy your Windows Forms applications because the majority of the ClickOnce interface is drawn from the .NET Framework Language Packs (see the “ClickOnce” section in Chapter 4, “Windows Forms Specifics”). Because you cannot create your own .NET Framework Language Packs, you cannot provide a ClickOnce user interface in your custom culture’s lan- guage (with the exception of the ClickOnce bootstrapper dialogs).
Custom Cultures in the .NET Framework 1.1 and Visual Studio 2003
The story for custom cultures in the .NET Framework 1.1 is considerably more lim- ited than for the .NET Framework 2.0, to the extent that if you are able to upgrade to the .NET Framework 2.0, I advise doing so. Assuming that this isn’t possible, read on.
A custom culture in the .NET Framework 1.1 is a new class that inherits from the CultureInfo class and sets the necessary CultureInfo properties to their relevant values in the constructor. The .NET Framework SDK includes an example of such a custom culture in <SDK>\v1.1\Samples\Technologies\Localization\Custom- Culture. To use the new custom culture, you must construct it using its own con- structor. If your custom culture class is called BengaliBangladeshCulture, for example, you construct it using this:
CultureInfo cultureInfo = new BengaliBangladeshCulture();
It is not possible to construct it using the culture’s name (e.g., “bn-BD”) because the list of cultures supported by the .NET Framework 1.1 is hard wired. Similarly, Visual Studio 2003 and WinRes 1.1 use the list supplied by the .NET Framework; therefore, it is not possible to make them aware of the custom culture, so both tools are useless for maintaining resources for the custom culture.