Best Practices for Developing World-Ready Applications
For full resource please visit: https://msdn.microsoft.com/en-us/library/w7x1y988(v=vs.110).aspx
- Make your application Unicode internally.
- Use the culture-aware classes provided by the System.Globalization namespace to manipulate and format data.
- For sorting, use the SortKey class and the CompareInfo class.
- For string comparisons, use the CompareInfo class.
- For date and time formatting, use the DateTimeFormatInfo class.
- For numeric formatting, use the NumberFormatInfo class.
- For Gregorian and non-Gregorian calendars, use the Calendar class or one of the specific calendar implementations.
- Use the culture property settings provided by the System.Globalization.CultureInfo class in the appropriate situations. Use the CultureInfo.CurrentCulture property for formatting tasks, such as date and time or numeric formatting. Use the CultureInfo.CurrentUICulture property to retrieve resources.Note that the CurrentCulture and CurrentUICulture properties can be set per thread.
- Enable your application to read and write data to and from a variety of encodings by using the encoding classes in the System.Text namespace. Do not assume ASCII data. Assume that international characters will be supplied anywhere a user can enter text. For example, the application should accept international characters in server names, directories, file names, user names, and URLs.
- When using the UTF8Encoding class, for security reasons, use the error detection feature offered by this class. To turn on the error detection feature, the application creates an instance of the class using the constructor that takes a throwOnInvalidBytes parameter and sets the value of this parameter to true.
- Whenever possible, handle strings as entire strings instead of as a series of individual characters. This is especially important when sorting or searching for sub-strings. This will prevent problems associated with parsing combined characters.
- Display text using the classes provided by the System.Drawing namespace.
- For consistency across operating systems, do not allow user settings to override CultureInfo. Use the CultureInfo constructor that accepts auseUserOverride parameter and set it to false.
- Test your application functionality on international operating system versions, using international data.
- If a security decision is based on the result of a string comparison or case change operation, have the application perform a culture-insensitive operation. This practice ensures that the result is not affected by the value of CultureInfo.CurrentCulture.
- Move all localizable resources to separate resource-only DLLs. Localizable resources include user interface elements, such as strings, error messages, dialog boxes, menus, and embedded object resources.
- Do not hardcode strings or user interface resources.
- Do not put nonlocalizable resources into the resource-only DLLs. This causes confusion for translators.
- Do not use composite strings that are built at run time from concatenated phrases. Composite strings are difficult to localize because they often assume an English grammatical order that does not apply to all languages.
- Avoid ambiguous constructs such as “Empty Folder” where the strings can be translated differently depending on the grammatical roles of the string components. For example, “empty” can be either a verb or an adjective, which can lead to different translations in languages such as Italian or French.
- Avoid using images and icons that contain text in your application. They are expensive to localize.
- Allow plenty of room for the length of strings to expand in the user interface. In some languages, phrases can require 50-75 percent more space than they need in other languages.
- Use the System.Resources.ResourceManager class to retrieve resources based on culture.
- Use Visual Studio to create Windows Forms dialog boxes, so that they can be localized using the Windows Forms Resource Editor (Winres.exe). Do not code Windows Forms dialog boxes by hand.
- Arrange for professional localization (translation).
- Explicitly set the CurrentUICulture and CurrentCulture properties in your application. Do not rely on defaults.
- Note that ASP.NET applications are managed applications and therefore can use the same classes as other managed applications for retrieving, displaying, and manipulating information based on culture.
- Be aware that you can specify the following three types of encodings in ASP.NET:
- requestEncoding specifies the encoding received from the client’s browser.
- responseEncoding specifies the encoding to send to the client browser. In most situations, this encoding should be the same as that specified for requestEncoding.
- fileEncoding specifies the default encoding for .aspx, .asmx, and .asax file parsing.
- Specify the values for the requestEncoding, responseEncoding, fileEncoding, culture, and uiCulture attributes in the following three places in an ASP.NET application:
- In the globalization section of a Web.config file. This file is external to the ASP.NET application.
- In a page directive. Note that, when an application is in a page, the file has already been read. Therefore, it is too late to specify fileEncoding and requestEncoding. Only uiCulture, Culture, and responseEncoding can be specified in a page directive.
- Programmatically in application code. This setting can vary per request. As with a page directive, by the time the application’s code is reached it is too late to specify fileEncoding and requestEncoding. Only uiCulture, Culture, and responseEncoding can be specified in application code.
- Note that the uiCulture value can be set to the browser accept language.
The .NET Framework uses attributes for a variety of reasons and to address a number of issues. Attributes describe how to serialize data, specify characteristics that are used to enforce security, and limit optimizations by the just-in-time (JIT) compiler so the code remains easy to debug. Attributes can also record the name of a file or the author of code, or control the visibility of controls and members during forms development.
This attribute definition demonstrates the following points:
- Attribute classes must be declared as public classes.
- By convention, the name of the attribute class ends with the word Attribute. While not required, this convention is recommended for readability. When the attribute is applied, the inclusion of the word Attribute is optional.
- All attribute classes must inherit directly or indirectly from System.Attribute.
By default, when you run a 64-bit managed application on a 64-bit Windows operating system, you can create an object of no more than 2 gigabytes (GB). However, in the .NET Framework 4.5, you can increase this limit.
By default, when you use the .NET Framework to build an application on either a 32-bit or a 64-bit computer, the application will run on a 64-bit computer as a native application (that is, not under WOW64).
WOW64 is a compatibility environment that enables a 32-bit application to run on a 64-bit system. WOW64 is included in all 64-bit versions of the Windows operating system.
The CLR header of a Visual Studio assembly has the major runtime version number set to 2 and the minor runtime version number set to 5. Applications that have the minor runtime version set to 0 are treated as legacy applications and are always executed under WOW64.
The run-time provides the following benefits:
- Performance improvements.
- The ability to easily use components developed in other languages.
- Extensible types provided by a class library.
- Language features such as inheritance, interfaces, and overloading for object-oriented programming.
- Support for explicit free threading that allows creation of multi threaded, scalable applications.
- Support for structured exception handling.
- Support for custom attributes.
- Garbage collection.
- Use of delegates instead of function pointers for increased type safety and security. For more information about delegates, see Common Type System.
To optimize the performance of the garbage collector, the managed heap is divided into three generations: 0 (New Objects), 1 (Older Objects), and 2 (Oldest Objects). The run time’s garbage collection algorithm is based on several generalizations that the computer software industry has discovered to be true by experimenting with garbage collection schemes. First, it is faster to compact the memory for a portion of the managed heap than for the entire managed heap. Secondly, newer objects will have shorter lifetimes and older objects will have longer lifetimes. Lastly, newer objects tend to be related to each other and accessed by the application around the same time.