How to Save Custom Cultures Without Administrative Privileges 

This topic describes a technique for saving custom culture data to a file without administrative privileges. An application running with administrative privileges registers a custom culture using Register. Internally this method calls the CultureDefinition.Compile method, which does not require administrative privileges.

To save custom cultures without administrative privileges, your application can access the CultureDefinition.Compile method directly, using reflection. However, using the method this way is unsupported and the method might change or be removed at any time.

Caution noteCaution

The CultureDefinition.Compile method will change without notice. This topic describes its behavior for .NET Framework version 2.0 only. The method will not work for any other versions of .NET. Misuse of this method can leave your computer in an unstable or partially working state, possibly resulting in application crashes or data loss.

The CultureDefinition.Compile method is a member of the internal System.Globalization.CultureDefinition class. CultureDefinition.Compile writes a custom culture to a file. However, since it does not write anything to the registry, it does not require administrative privileges.

Because it is an internal method, CultureDefinition.Compile might not be available or might have different behavior in different versions of .NET. Therefore, when calling this method directly, your application should be bound to .NET Framework version 2.0, on which the following description of CultureDefinition.Compile is based. The method as described here is technically operational, but is not supported and should not be considered safe.


internal static void Compile(

CultureAndRegionInfoBuilder Builder,

String Outfile




The System:Globalization:CultureAndRegionInfoBuilder object to read. The conditions on this object are the same as for CultureAndRegionInfoBuilder.Register.


A System:String object representing the full path to the output file. The method writes the custom culture file but does not properly register it. The output file does not function correctly, even if placed in the %windir%\globalization directory.


Because this is an unsupported private method, the list of exceptions thrown and the meanings of the exceptions can change without notice. Any exception should be considered a failure.


The following are the differences between CultureAndRegionInfoBuilder.Register and CultureDefinition.Compile:

  • CultureAndRegionInfoBuilder.Register is a supported public method. As an internal method, CultureDefinition.Compile is subject to change or removal in future versions and should not be relied upon.

  • CultureAndRegionInfoBuilder.Register requires administrative permissions but CultureDefinition.Compile writes to any file the user has permission to create.

  • CultureAndRegionInfoBuilder.Register performs more validation than CultureDefinition.Compile. Thus, calling the latter method directly can create an invalid culture that normally cannot be installed on a computer. The created culture might contain irregular data or data that can cause the operating system or .NET Framework to fail.

  • CultureAndRegionInfoBuilder.Register always creates its output file in the %windir%\globalization directory. CultureDefinition.Compile writes to any specified output file.

  • CultureDefinition.Compile might throw an exception if the CultureAndRegionInfoBuilder object specified by the Builder parameter contains inconsistent or unexpected data. However, this method does not validate as thoroughly as CultureAndRegionInfoBuilder.Register.

Caution noteCaution

Since CultureDefinition.Compile uses limited validation mechanisms, it can create invalid or inconsistent cultures, potentially leading to application crashes or even to data loss.

  • CultureAndRegionInfoBuilder.Register registers the custom culture file in the registry. CultureDefinition.Compile creates a custom culture but does not register (install) it on the local operating system. Unregistered files in the %windir%\globalization directory fail in Windows Vista and are not fully functional in .NET Framework version 2.0. Although they might appear operable, improperly registered custom culture files cause GetCultureNameFromIetfName to fail. These files cause erratic behavior or failures if accessed from Windows Vista, for example, by calling GetLocaleInfoEx in the National Language Support (NLS) API.

  • When the application calls CultureAndRegionInfoBuilder.Register, this method sets the following registry keys in addition to creating the custom culture file. These keys are missing if the application calls only CultureDefinition.Compile.

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CustomLocale. In this key, the method creates a string value named with the locale name, with the string data containing the culture name.

  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\IetfLanguage. In this key, the method creates a string value named with the Internet Engineering Task Force (IETF) tag for the culture. The data for this value contains the culture name to use with the tag.

To save custom cultures using CultureDefinition.Compile:

  1. Include code in your application to perform validations as required. Remember that additional validations made by the CultureAndRegionInfoBuilder.Register method are omitted when you use the Culture method directly. Although the resulting culture will be accessible, improperly constructed files might exhibit illegal or erratic behavior.

  2. Where your application normally calls CultureAndRegionInfoBuilder.Register, have it call CultureDefinition.Compile, passing the CultureAndRegionInfoBuilder object along with an appropriate file name.

  3. Register the resulting custom culture file as described in the next procedure.

To register (install) the custom culture file:

  1. Include code in your application to write the output of the CultureDefinition.Compile call to %windir%\globalization.

  2. To enable the custom culture to succeed in Windows Vista and .NET Framework 2.0, include code to write to the following registry keys as described in the Remarks section: