Development World

New Development Technologies , Computer Last News , Tips & Tricks , UI , CSS , HTML , ASP , C# , .net Framework , Patterns & Practices & etc

How To Implement a Single DLL for each Localized Language (Satellite Assembly)

Dear Friends , Recently I'd a problem with Resource files, I wanted to create a single DLL for each local language in my application , by default microsoft visual studio , create a seperate resource file per App_localResources folder in application , ( all resource files in a app_LocalResources , merged in a single dll , it's redo for all foبlders ) .

this is not but in common , but if you deploy application per week , or in a small time stamp , you'll get headech!! , becouse of the big time that will take resource file deploy , ( in my application more than 20 minutes it waste time ) .

I check for a solution that once deploy resources , and never build them after that , there is some way and the best one is to use Sattellite assembly , I'd read a good article on , how to create a satelite assembly for each local language , and enjoy it , now I want to share it with you ,

the article provided with Francesco Balena in : http://visualstudiomagazine.com/columns/article.aspx?editorialsid=1932

---------------------------------------------------------------------------------------------------------

Use Satellite Assemblies for Localized Resources
Once you know how to add a resource file to your project, you're ready to use satellite assemblies to hold all the strings and other resources that your main application uses, such as images and WAV files. You must mark satellite assemblies with an AssemblyCulture attribute and avoid placing any executable code in them. The name of a compiled satellite assembly should include the .resources word (as in MyApp.resources.dll for a main assembly named MyApp.dll).

You can create one or more satellite assemblies with localized resources from inside VS.NET. In this example, you'll create a satellite assembly holding Italian resources for an application named MyApp. First, create a new class library project either in the same solution as the main application or in a different solution. The name of this project isn't important, but you might want to use a name formed by appending the name of the main project and the culture identifier. For example, you might name the project MyApp_it_IT, because the satellite assembly will contain resources for the it-IT culture. Delete the Class1.vb or Class1.cs file that .NET creates for a class library project.

Go to the General page of the new project, change the assembly name to match the name of the main application (MyApp, in this example), and change the default namespace (C#) or the root namespace (Visual Basic) to match the default or root namespace of the main application. In general, the namespace should match your company's name (in this example, it's CodeArchitects).

Go to the Build page of the Project Properties dialog box, and change the Output path value to point to the subdirectory where you create the main application's assembly. For example, if the main project is stored in the C:\Projects\MyApp folder, the output directory for both the main executable and its satellite assemblies should be C:\Projects\MyApp\bin.

Next, add an AssemblyCulture attribute that specifies the culture of the satellite assembly in the AssemblyInfo.vb or AssemblyInfo.cs file:

' [Visual Basic]
<Assembly: AssemblyCulture("it-IT")>

// [C#]
[assembly: AssemblyCulture("it-IT")]

Now you're ready to add one or more resources to the satellite assembly, by following the procedure outlined in the "Don't Burn Strings in Code" section. However, it's essential that all the RESX files you create embed the culture name in their name. For example, a file containing all the Italian strings should be named Strings.it-IT.resx. Don't place the resource file in a C# project subfolder, because this action affects the name you use to reference the resource file.

Now you can compile the satellite assembly as usual. VS.NET recognizes the AssemblyCulture attribute and correctly creates an assembly named MyApp.resources.dll. This assembly is created in a subdirectory named after the assembly culture, under the output folder. In this example, the path of the folder is C:\Projects\MyApp\bin\it-IT. The .NET runtime will look for Italian resources in this folder.

Notice that Visual Studio .NET also creates the "standard" MyApp.dll assembly in the output folder (C:\Projects\MyApp\bin, in this example). This assembly contains no code and no resources, and you can delete it before deploying the application.

You can go back to the main application and run the same code used to read a resource from a resource file embedded in the main application (see Listing 1). If the code is running under an Italian version of Windows, or if you've changed the locale assigned to the current UI thread to request Italian resources, then the ResourceManager uses the resources stored in the satellite assembly in the it-IT subdirectory.

A direct consequence of the way the ResourceManager object looks for resources is that resources related to the default locale are located only after checking that no subdirectory for that culture exists. This means, for example, that all the resources for an application whose default culture is en-US are loaded only after checking that no en-US folder exists under the app's main directory.

You can avoid this little overhead by applying the NeutralResourcesLanguage attribute to the main assembly to inform the resource manager about the language for the neutral resources that are embedded in the main assembly:

' [Visual Basic]
<Assembly: _
NeutralResourcesLanguage("en-US")>

// [C#]
[assembly:
NeutralResourcesLanguage("en-US")]

Bear in mind that you should never use AssemblyCultureAttribute in the main assembly. The main assembly should contain only neutral resources—that is, strings and bitmaps related to the default language.

-----------------------------------------------------------------------------------------------------------

also there is another good article on localization , that I read at : http://edndoc.esri.com

Using resources with localization

This section explains how you can localize resources for your customizations.

How to use resources with localization

In .NET, a combination of a specific language and country/region is called a culture . For example, the American dialect of English is indicated by the string "en-US", and the Swiss dialect of French is indicated by "fr-CH".

If you want your project to support various cultures (languages and dialects), you should construct a separate .resources files containing culture-specific strings and images for each culture.

When you build a .NET project that uses resources, .NET embeds the default .resources file in the main assembly. Culture-specific .resources files are compiled into satellite assemblies (using the naming convention <Main Assembly Name>.resources.dll) and placed in subdirectories of the main build directory. The subdirectories are named after the culture of the satellite assembly they contain. For example, Swiss-French resources would be contained in an fr-CH subdirectory.

When an application runs, it automatically uses the resources contained in the satellite assembly with the appropriate culture. The appropriate culture is determined from the Windows settings. If a satellite assembly for the appropriate culture cannot be found, the default resources (those embedded in the main assembly) will be used instead.

A developer sample with localization

The Visual Basic .NET and C# flavors of the Pan Tool developer sample illustrate how to localize resources for German language environments.  The sample can be found in the Developer Samples\ArcMap\Commands and Tools\Pan Tool folder. Strictly speaking, the sample only requires localized strings, but the images have been changed for the "de" culture as well, to serve as illustration.

A batch file named buildResources.bat has been provided in the Pan Tool sample to facilitate creating the default .resources files and the culture-specific satellite assemblies. See the following sections for more information on creating your own .resx and .resources files.

Embedding a default .resources file in your project

1. Right-click the project name in the Solution Explorer, click Add, then click Add Existing Item to navigate to your .resx or .resources file.
2. In the Solution Explorer, choose the file you just added and press F4 to display its Properties.
3. Set the Build Action property to Embedded Resource.

This will ensure that your application always has a set of resources to fall back on if there isn�t a resource DLL for the culture your application runs in.

Creating .resources.dll files for cultures supported by your project

1. First, ensure you have a default .resx or .resources file in your project.
2. Take the default .resx or .resources file and create a separate localized file for each culture you want to support.
• Each file should contain resources with the same Names; the Value of each resource in the file should contain the localized value.
• Localized resource files should be named according to their culture, for example, <BaseName>.<Culture>.resx or <BaseName>.<Culture>.resources.
3. Add the new resource files to the project, ensuring each one has its Build Action set to Embedded Resource.
4. Build the project.

The compiler and linker will create a separate satellite assembly for each culture. The satellite assemblies will be placed in subdirectories under the directory holding your main assembly. The subdirectories will be named by culture, allowing the .NET runtime to locate the resources appropriate to the culture in which the application runs.

The main (default) resources file will be embedded in the main assembly.

نویسنده : Nasser Hajloo : ۳:٥٢ ‎ب.ظ ; ۱۳۸٧/٥/۱٧
پيام هاي ديگران ()      لینک دائم