Compatibility

This section covers the compatibility between the two versions of the .NET Framework and Visual Studio.

Windows Forms Compatibility

Visual Studio 2005 serializes components on a form using a model called Property Reflection (see Chapter 4, "Windows Forms Specifics"). Visual Studio 2003, however, serializes components using a model called Property Assignment. When you open a Visual Studio 2003 solution in Visual Studio 2005, it prompts you to convert the solution, giving you an opportunity to back up the old solution. The forms files (i.e., the .cs, .resx, and culture-neutral and culture-specific .resx files) are all initially unchanged and remain compatible with Visual Studio 2003. However, after a form has been changed, the source and resx files are written out using Visual Studio 2005's Property Reflection model. The resulting code and resx files are now different. Although Visual Studio 2003 doesn't use the Property Reflection model, the resulting code and resx files are recognizable and can be opened and compiled using Visual Studio 2003 (assuming that the form contains only components and code that both platforms recognize). Unfortunately, Visual Studio 2003 fails to understand that the form's Localizable property should be TRue and sets it to false. When you set it to true again, Visual Studio 2003 naturally rewrites the source file and resx file, and the form returns to Visual Studio 2003's Property Assignment model.

The upshot of all this is that both versions of Visual Studio can read each other's form files (as long as you use components that are present in both versions of the framework). However, when you make any change to a form, the version of Visual Studio you are using writes out the form again using the model that it uses to write forms. Because Visual Studio 2003 doesn't understand Visual Studio 2005's serialization of the form's Localizable property, you must set this to TRue again; this constitutes a change, which, therefore, means that the form is converted back to Visual Studio 2003's model. You should also be aware that the scenario of opening Visual Studio 2005 forms in Visual Studio 2003 is not an officially supported model, so although this is often possible, you are on your own with regard to support.

Windows Forms Designer

The Visual Studio 2005 Windows Forms Designer adds many enhancements beyond the Visual Studio 2003 Windows Forms Designer, but it also removes one area of functionality. In the Visual Studio 2003 Windows Forms Designer, you can add new controls to any language version of a form. For example, with the French version of a form selected in the designer, you can add a new button to the form and it will be added to all forms. The Visual Studio 2005 Windows Forms Designer, however, requires that you first change back to the default language before adding new controls. Instead of viewing this as a step backward in Visual Studio 2005, you should understand that Visual Studio 2003 should not have allowed new controls to be added to forms other than the default language form, but this practice was not explicitly prevented.

CultureInfo.DisplayName and CultureInfo.EnglishName with Scripts

The format of the text returned by the CultureInfo DisplayName and English-Name properties for some cultures with scripts has changed. The format used in the .NET Framework 1.1 is to delimit the script entirely in its own parentheses. For example, the culture for the Azeri language in Azerbaijan using the Latin script ("az-AZ-Latn") has this EnglishName:

 Azeri (Latin) (Azerbaijan) 

However, the .NET Framework 2.0 includes the script in the same parentheses as the country:

 Azeri (Latin, Azerbaijan) 

If you have logic that parses the name to extract its component information, you need to update this logic. Note that this change does not apply to new cultures with script suffixes that were introduced in the .NET Framework 2.0. For example, the "sr-BALatn" culture's EnglishName is "Serbian (Latin) (Bosnia and Herzegovina)".

CultureInfo.GetCultures Order

The order of the cultures returned from the CultureInfo.GetCultures method is different between the two versions of the framework. The order in both versions of the .NET Framework is unsorted and unspecified, but they are nonetheless different.

Control.DefaultFont Logic

The logic used to determine the DefaultFont property of System.Windows.Forms. Control is slightly more sophisticated in the .NET Framework 2.0. Because Control is the base class for all Windows Forms controls, this affects all controls. The difference is that on Arabic Windows, Control.DefaultFont now defaults to Tahoma, 8 point.

CultureInfo.Equals Logic

The logic used in the CultureInfo.Equals method has changed. In the .NET Framework 1.1, CultureInfo.Equals tests equality with another CultureInfo by comparing their locale IDs (LCIDs). In the .NET Framework 2.0, this comparison does not work because custom cultures all share the same LCID. Thus, a Spanish (United States) custom culture has the same LCID as a Bengali (Bangladesh) custom culture. In the .NET Framework 2.0, the CultureInfo.Equals method assumes that two cultures are equal if they have the same name and the same CompareInfo objects. (A test based simply on a name would be incorrect because alternate sort orders have the same culture name but different sort orders.) I have not found any circumstance in which this difference causes an incompatibility.

CultureInfo.OptionalCalendars Has New Calendars

The .NET Framework 2.0 introduces new calendar classes. These new calendars classes are available to the cultures for which they are relevant through the CultureInfo.OptionalCalendars array property. Consequently, the lengths of these arrays and, perhaps more important, the order of the elements of these arrays are different in some cultures (e.g., Arabic (Saudi Arabia)).

Base Data Has Changed for Some Cultures

The month and day names returned by the DateTimeFormatInfo, MonthNames, and DayNames array properties have changed for the Arabic (Morocco), Divehi (Maldives), Kannada (India), and Norwegian (Nynorsk) (Norway) cultures (i.e., ar-MA, div-MV, kn-IN, and nn-NO).

In addition, the currency symbols have been updated for several cultures, including Turkish (Turkey) (i.e., tr-TR), for which the currency symbol in the .NET Framework 1.1 is "TL" (Türk Lirasi); however, in the .NET Framework 2.0, the currency symbol is "YTL" (Yeni Türk Lirasi), regardless of the version of Windows and whether Windows Updates is turned on.

ResX Relative File References Break Code That Uses ResXResourceReader

The Visual Studio 2005 Resource Editor includes support for adding files such as bitmaps to resx resource files. The resulting entry in the resx file is of type ResXfileref. The ResXFileRef class is supported in both the .NET Framework 1.1 and 2.0. The problem (from the point of view of code that reads resources), however, is that the Visual Studio 2005 Resource Editor uses relative paths (see the "ResX File References" section in Chapter 10, "Resource Administration"). If you process resx files using the ResXResourceReader class, in most cases your code that reads resx files will fail if it tries to read a .NET Framework 2.0 resx file because it won't know where to find the referenced files. A number of solutions exist, but the simplest is to set the ResXResourceReader.BasePath property to the path where the referenced files are located.

ResX Changes Break Code That Uses ResXResourceReader

The serialization of the Form.Localizable property to resx files has changed. In the .NET Framework 1.1, this property was represented as data in the resx file like this:

 <data name="$this.Localizable" type="System.Boolean, mscorlib, Version=1.0.5000.0, Culture=neutral,PublicKeyToken=b77a5c561934e089">   <value>True</value> </data> 

In the .NET Framework 2.0, however, the same property is represented like this:

 <metadata name="$this.Localizable" type="System.Boolean, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">   <value>True</value> </metadata> 

The difference is that the Form.Localizable property is now treated as meta-data instead of data. This has an impact on any code that reads resx files using the ResXResourceReader.GetEnumerator() method. The following code adds all the entries in a resx file to a TextBox:

 ResXResourceReader reader =     new ResXResourceReader(@"..\..\Form1.resx"); IDictionaryEnumerator enumerator = reader.GetEnumerator(); while (enumerator.MoveNext()) {     DictionaryEntry entry = enumerator.Entry;     string value = String.Empty;     if (entry.Value != null)         value = entry.Value.ToString();     textBox1.Text += entry.Key.ToString() + ", " + value +         System.Environment.NewLine; } 

In the .NET Framework 1.1, this code includes the $this.Localizable enTRy. In the .NET Framework 2.0, it does not. To read this entry in the .NET Framework 2.0, you need to use the new ResXResourceReader.GetMetadataEnumerator method:

 ResXResourceReader reader =     new ResXResourceReader(@"..\..\Form1.resx"); IDictionaryEnumerator enumerator = reader.GetMetadataEnumerator(); while(enumerator.MoveNext()) {     DictionaryEntry entry = enumerator.Entry;     textBox1.Text += entry.Key.ToString() + ", " +         entry.Value.ToString() + System.Environment.NewLine; } 

This code results in just a single entry (i.e., $this.Localizable).

In addition, the change from data to metadata affects any FxCop rule that reads resource data looking for the Form.Localizable property. See the "Form. Localizable must be true" rule in Chapter 13, "Testing Internationalization Using FxCop," for an example.