would happen if your application was installed on a machine first. All would be well right up until the second application overwrote your custom culture with its defini- tion of the same culture. That application would function correctly. The best-case sce- nario for your application is that it would fail. The worst-case scenario is more likely: Your application would continue to function but would be incorrect.
A number of limited solutions exist, depending on whether you are creating a replacement custom culture or a supplemental custom culture. Let’s start with sup- plemental custom cultures. A supplemental custom culture is a completely new cul- ture that the .NET Framework and the operating system have not seen. The best solution here is to solve the problem by avoiding the problem (this is often my favorite solution to any problem). The solution lies in using a naming convention in which uniqueness is built into name. A simple solution would be to suffix the culture name with your company’s name. So if you create a supplemental custom culture for Bengali as spoken in Bangladesh (i.e., “bn-BD”) and your company is the Acme Cor- poration, you would name the culture “bn-BD-Acme”. Alternatively, you could take a more certain but completely unreadable solution of suffixing with a GUID—e.g., “bn-BD-b79a80f4-2e22-4af5-9b79-e362304b-5b10” (note that the GUID has been split into chunks of eight characters or less). The naming convention solution also has the benefit of being future-proof. Change is certain. Microsoft will add new cultures to Windows. If Microsoft adds the bn-BD culture to Windows, code that cre- ates a custom “bn-BD” culture that used to work will throw an exception in the Cul- tureAndRegionInfoBuilder constructor:
CultureAndRegionInfoBuilder builder = new CultureAndRegionInfoBuilder(“bn-BD”, CultureAndRegionModifiers.None);
If the culture name is suffixed to make the culture name unique, it cannot clash with new cultures or other companies’ custom cultures. The downside to this nam- ing is that it is a considerable abuse of the IETF tag that the suffix replaces. You must decide which is the lesser evil.
On the subject of supplemental custom culture names, the IETF defines a prefix (“x-” or “X-”) that should be used for what are called “private” cultures (e.g., “x- bn-BD”). Don’t be confused by the use of the word “private”—the cultures are still publicly available to all .NET Framework 2.0 applications. The difference is that, by