When you package your application's resources, you must name them using the resource naming conventions that the common language runtime expects. The runtime identifies a resource by its culture signature, or name. Each culture is given a unique name, which is a combination of a two-digit lowercase culture name associated with a language and, if required, a two-digit uppercase subculture name associated with a country or region. The subculture name follows the culture name, separated by a dash (-). Examples include ja-JP for Japanese in Japan or en-US for US English.
Naming pattern conventions
.resources files:
<myproject>.<xx-XX>.resources
Satellite assemblies
<myproject>.resources.dll
Location for satellite assemblies
The hub and spoke model requires that you place resources in specific locations, so that they can be easily located and used. If you do not compile and name resources as expected, or if you do not place them in the correct locations, the common language runtime will not be able to locate them. If your application includes resources for subcultures, place each subculture in its own directory. Do not place subcultures in subdirectories of their main culture's directory.
Servicing the main assembly without revising the satellite assemblies- SatelliteContractVersionAttribute
Directory locations for satellite assemblies:
- A subdirectory per culture
- Either neutral or specific cultures can be used
Myproject.dll
\fr\myproject.resources.dll (neutral)
\de-DE\myproject.resources.dll (specific)
Installing satellite assemblies into the global assembly cache (GAC)
- assemblies need to be strong-named (SN tool)
- a strong name consists of a name, version number and culture combined with a digital signature
An alternative to laying out the satellite assemblies in a directory structure is to install them into the global assembly cache (GAC). This has several advantages compared to the directory layout especially for assemblies shared between many different applications. One prerequisite for an assembly to be installed into the GAC is that the assembly is strong named – this is basically providing a identification (name, version number and culture) and a digital signature for the assembly. Also, when the satellite assemblies are installed to the GAC, the main assembly has to be present in the GAC too. The exact process for installing an assembly into the cache is described in the .NET Framework documentation.
An feature related to naming and layout is that the .NET Framework resource model allows you to service a main assembly without necessarily having to revise the satellite resource assemblies. If a solution to a bug only requires changing the code in the main assembly without having to change any user interface the existing localized satellite assemblies can be reused by keeping SatelliteContractVersionAttribute of the main assembly the same. To provide the bug fix to users only the main assembly has to be redeployed. This also works the other way around – servicing the satellite assembly without revising the main assembly, for example to correct a translation error.