Common Resource Concepts

Most aspects of programming with the .NET Framework are the same for all compatible languages, because each supported language compiler produces self-describing, managed, Microsoft intermediate language (MSIL) code. All managed MSIL code runs against the common language runtime, which provides cross-language integration, automatic memory management, cross-language exception handling, a high level of security, and a simplified model for component interaction. In addition to the runtime, the .NET Framework includes the .NET Framework class library, which can also be accessed by any language that is compatible with .NET. Several aspects of this common development process are particularly important when building applications that use resources.

Building Blocks

The .NET Framework class libraries that you and others create are also organized into hierarchical namespaces and are stored in portable executable (PE) files — typically DLL and EXE files. You can have several namespaces — including nested namespaces — in one PE file, and you can split a namespace across multiple PE files. One or more PE files (and possibly other types of files, such as resources) are combined together to create an assembly, which is a physical unit that can be deployed, version numbered, and re-used. The runtime uses assemblies to locate and bind to the referenced types. Resources can also be bound into assemblies, or they can be packaged separately in several different formats, or they can even be used as individual files — like JPEG images — for convenience. Information about what is in an assembly — including classes and resources — is contained in the assembly manifest

Cultures

In the .NET Framework, culture refers to the user's language optionally combined with that user's location. By specifying a culture, it is possible to use a set of common preferences for certain information — such as strings, date formats, and number formats — that corresponds to the user's language and location conventions.

The location can be a country or a region; the latter might be the geopolitically correct term in a location where a country is not officially recognized. The language and location can be specified by the codes that are defined by the Internet RFC 1766, "Tags for the Identification of Languages." The actual codes themselves are defined by two ISO standards: ISO 639, "Code for the representation of names of languages," and ISO 3166, "Codes for the representation of names of countries." See the topic, "Language and Country/Region Tags" in Appendix A: Additional Resource Information for additional reference information on these standards.

Detailed cultures' preferences can be accessed using instances of the CultureInfo class, which are in turn accessed using culture tags. Culture tags use the format primary[-secondary], where the primary tag is the language and the optional secondary tag is the country/region code. By convention, the language tag consists of two lowercase letters, and the country/region tag consists of two uppercase letters. The following table contains examples of culture tags.

In the .NET Framework, two-letter tags indicate neutral, language-only cultures, such as de for German. Four-letter tags indicate specific cultures, such as fr-CA for French as spoken in Canada. In most situations, the user interface is specified as a specific culture. However, in a number of cases — such as ja-JP for Japan Japanese —only one specific culture exists for a particular neutral culture and, in such a case, the two tags are often used interchangeably. If it is necessary for an application to be able to set a culture to a specific culture — perhaps in response to an Internet browser setting — the application should map all neutral cultures to matching specific cultures using the CreateSpecificCulture method.

Culture in the .NET Framework takes the place of the national language support (NLS) locale, which used a system of locale ID (LCID) codes. The LCID property of the CultureInfo class provides interoperability and eases integration with NLS-based software.

.NET Resource Classes

The .NET Framework class library offers several classes to aid developers in working with resources in their applications and tools.

The ResourceManager Class

The ResourceManager class (in the System.Resources namespace) provides convenient access to culture-correct resources at run time. This class provides resource fallback (typically to the neutral culture) when a localized resource does not exist, supports resource serialization, and provides the CreateFileBasedResourceManager method to allow access to resources that are not packaged in your assembly. Of course, developers can also derive classes from ResourceManager when creating custom resource solutions.

ResourceWriter Class

The ResourceWriter class (in the System.Resources namespace) writes resources in the system's default format to an output file or stream. Resources are specified as name-value pairs using the AddResource method. Resource names are case-sensitive when used for lookups, but a ResourceWriter does not write a resource name to a .resources file if that name varies only by case. The ResourceWriter class provides a default implementation of the IResourceWriter interface and can be overridden by the developer.

**Note   **Resources are not necessarily written in the same order that they were added programmatically.

ResourceReader Class

The ResourceReader class (in the System.Resources namespace) enumerates .resources files and streams, and reads sequential resource name-value pairs. This class provides a default implementation of the IResourceReader interface which, like the ResourceWriter class, the developer can override.

ResourceSet Class

The ResourceSet class (in the System.Resources namespace) stores all resources that are localized for one particular culture. All resources are immediately loaded into memory. Unlike the ResourceManager, the ResourceSet does not fall back. Because of this, the ResourceSet is useful primarily when creating tools and utilities but not in localized applications. The ResourceSet can also be used to control resource caching (for example, to prevent caching images).

CultureInfo Class

The CultureInfo class (in the System.Globalization namespace) simply contains a set of user-preference information, which is dependent on the user's language, sublanguage, country/region, and cultural conventions. This class is used to format dates, times, and numbers; sort strings; and determine the language choice for text.

RegionInfo Class

The RegionInfo class (in the System.Globalization namespace) is used to determine the unit of measurement and to map region codes to region names.

Assembly.GetManifestResourceStream Method

The Assembly.GetManifestResourceStream method (in the System.Reflection namespace) loads manifest resource data directly into a stream. This is particularly useful when resources are stored in custom formats, which a ResourceManager would not be able to natively understand.

**Note   **To use the Assembly.GetManifestResourceStream method, the resources must be located in an assembly.

Thread.CurrentUICulture Property

The Thread.CurrentUICulture property (in the System.Threading namespace) is useful when it is necessary to determine the current culture or, more importantly, to set the culture to emulate running under a different localized version of Windows. This is necessary because Control Panel cannot show multiple user interface LCIDs in a version of Windows 2000 that does not have a multilingual user interface. Instead, the culture can be set programmatically at run time on a per-thread basis.

Deployment

In the simplest case, a stand-alone .NET Framework executable file can be executed locally on any computer that the common language runtime is already installed on. Nothing else is required — no registry entries are made, nothing can break another application or cause it to stop running, and simply deleting the file (if it is copied locally) is enough to clean up the application and leave a zero footprint on the computer. Applications run from a URL that represents a Web site behave slightly differently. In these cases, assemblies are installed in the download cache and are later scavenged automatically. All other applications, including those from a URL that represents a file, are run from source code and are not cached anywhere on the local computer.

Distribution

Of course, most client applications will be further packaged into a common distribution format — such as a .cab or .msi file — and many will be installed using application-distribution mechanisms such as Windows 2000 IntelliMirror or Microsoft Systems Management Server (SMS), which both use the Microsoft Installer technology. For more on the Microsoft Installer, please refer to the corresponding section in the Win32 SDK.

See Also

Creating Resources | Retrieving Resources Using Code | Resources Summary | Appendix A: Additional Resource Information | Appendix B: Resource Tools