.NET Compact Framework 3.5 Run-Time Breaking ChangesSome new behaviors have been implemented with “Version Coercions” which provide previous behavior compatibility to support applications built with previous versions of the .NET Compact Framework. To learn more about Version Coercions and how .NET Compact Framework compatibility works, please refer to the following information from the .NET Compact Framework team: Globalization | | Description | Update globalization tables | | Previous Behavior | Unicode 3.0;
zh-CHS and zh-CHT are not supported;
Chinese - PRC culture 0x0804 name is zh-CN_pronun;
English - Caribbean 0x2409 name is en-CB;
Spanish - Mexico 0x080a has currency Mexican Peso;
Serbian cultures contained references to Montenegro;
Turkish currency is Turkish Lira;
Azeri culture names for LCIDS 0x002c, 0x042c, 0x082c are az-AZ-Latn and az--AZ-Cyrl;
Georgian culture 0x0437 name is ka-GE_tradn;
Uzbek cultures 0x0043 and 0x0843 names are uz-UZ-Latn to uz-Latn-UZ;
Divehi cultures 0x0065 and 0x0465 name is div-MV;
Serbia Latin (0x081a) has no special sorting exceptions or compression tables |
| | New Behavior | Unicode 5.0;
zh-CHS and zh-CHT are supported;
PRC culture 0x0804 name is zh-CN_stroke and its abbreviated day names have been updated;
English - Caribbean 0x2409 name is en-029;
Spanish - Mexico 0x080a now has currency "Mexican Nuevo Peso";
Serbian cultures no longer contain references to Montenegro;
Turkish currency changed to "New Turkish Lira";
Azeri culture names for LCIDS 0x002c, 0x042c, 0x082c are az-Latn-AZ and az-Cyrl-AZ;
Georgian culture 0x0437 name is ka-GE_modern;
Uzbek cultures 0x0043 and 0x0843 names are uz-UZ-Cyrl to uz-Cyrl-UZ;
Divehi cultures 0x0065 and 0x0465 name is dv-MV;
Serbia Latin (0x081a) uses the same sorting exceptions and compression tables as Croatian (0x041a) |
Loader | | Description | Configuration file binding redirections revert back to the old version if the new version does not exist | | Previous Behavior | If you have a binding redirect, but the redirected version of the assembly is not on the device, the .NET Compact Framework loads the original version of the assembly if it's in the GAC (Global Assembly Cache). |
| | New Behavior | If you have a binding redirect, the .NET Compact Framework only loads the redirected version of the assembly. |
System.AppDomain.UnhandledException | | Description | Behavior variations for exceptions passing through Windows Forms | | Previous Behavior | In the .NET Compact Framework 1.0, exceptions on any thread in an AppDomain should cause every thread in that AppDomain that is using a WinForms message pump to begin to shut down that thread. If the shutdown is interrupted, the exception will stop unwinding. An exception will not cause unwinding through multiple layers of dialog boxes. A catch clause will be effective for catching exceptions, and may prevent further unwinding. There are numerous cases in which an exception fails to start AppDomain shutdown, and as a result the application will continue running, and upon application termination a confusing error dialog box will appear.
In the .NET Compact Framework 2.0, exceptions on any thread in an AppDomain will cause every thread in that AppDomain that is using a WinForms message pump to begin shutdown of that thread. The shutdown of the message pump is not cancellable, and works in all known cases. A catch clause is not effective for preventing WinForms from shutting down. |
| | New Behavior | In the .NET Compact Framework 3.5, an exception will unwind as one would expect in standard .NET exception control flow. If the exception is unhandled after the second chance exception handling, ThreadAbortExceptions will propagate through all threads in that AppDomain. A catch clause is able to usefully catch exceptions. |
System.Collections.DictionaryEntry | | Description | System.Collections.DictionaryEntry should allow null keys | | Previous Behavior | In the .NET Compact Framework 1.0 and .NET Compact Framework 2.0, an ArgumentNullException was thrown when a null key was passed to DictionaryEntry using the Key property or in the contructor. |
| | New Behavior | In the .NET Compact Framework version 3.5, null keys are allowed. |
System.Collections.Generics | | Description | System.InvalidCastException for enumerator on generic dictionary | | Previous Behavior | .NET Compact Framework 2.0: In the following code the IEnumerator.Current property returns an object of the DictionaryEntry type:
Dictionary <int, string> dictionary;
IEnumerator enumerator;
dictionary = new Dictionary<int, string>();
dictionary.Add(0, "");
enumerator = dictionary.GetEnumerator();
enumerator.MoveNext();
// the Current property returns a DictionaryEntry object
element = enumerator.Current;
|
| | New Behavior | .NET Compact Framework 3.5: In the following code the IEnumerator.Current property returns an object of the KeyValuePair <int, string> type: Dictionary<int, string> dictionary;
IEnumerator enumerator;
dictionary = new Dictionary<int, string>();
dictionary.Add(0, "");
enumerator = dictionary.GetEnumerator();
enumerator.MoveNext();
// the Current property returns a
// KeyValuePair<int, string> object
element = enumerator.Current;
To get a DictionaryEntry object from IEnumerator.Current on .NET Compact Framework 3.5, you need to cast the dictionary object to System.Collections.IDictionary before calling the GetEnumerator() method. For example: enumerator = ((System.Collections.IDictionary)
dictionary).GetEnumerator();
enumerator.MoveNext();
// in this case, the Current property returns a
// DictionaryEntry object on .NET Compact Framework
// v3.5 and v2.0
element = enumerator.Current;
|
System.Collections.Generics.SortedDictionary | | Description | APSystem.Collections.Generics.SortedDictionary.exe fails with System.InvalidCastException: Specified cast is not valid error | | Previous Behavior | .NET Compact Framework 2.0: In the following code the IEnumerator.Current property returns an object of the DictionaryEntry type: SortedList<int, string> list;
IEnumerator enumerator;
list = new SortedList<int, string>();
list.Add(0, "");
enumerator = list.GetEnumerator();
enumerator.MoveNext();
// the Current property returns a DictionaryEntry object
element = enumerator.Current;
|
| | New Behavior | .NET Compact Framework 3.5: In the following code the IEnumerator.Current property returns an object of the KeyValuePair<int, string> type: SortedList<int, string> list;
IEnumerator enumerator;
list = new SortedList<int, string>();
list.Add(0, "");
enumerator = list.GetEnumerator();
enumerator.MoveNext();
// the Current property returns a
// KeyValuePair<int, string> object
element = enumerator.Current;
To get a DictionaryEntry object from IEnumerator.Current on the .NET Compact Framework 3.5, you need to cast the dictionary object to System.Collections.IDictionary before calling the GetEnumerator() method. For example: enumerator = ((System.Collections.IDictionary)list).GetEnumerator();
enumerator.MoveNext();
// in this case, the Current property returns a
// DictionaryEntry object on .NET Compact Framework
// v3.5 and v2.0
element = enumerator.Current;
|
System.DateTime | | Description | System.DateTime '+' and '-' operators throw Overflow Exception on .NET Compact Framework | | Previous Behavior | ArgumentOutOfRangeException on full .NET Framework |
| | New Behavior | If the result of DateTime.op_Addition or DateTime.op_Subtraction is less than MinValue or greater than MaxValue, throw ArgumentOutOfRangeException. |
System.Drawing.Graphics | | Description | Graphics.DpiX and DpiY are dependent on the DPI of the graphics object. | | Previous Behavior | In .NET Compact Framework 2.0, the DpiX and DpiY property reported the DPI of the screen, and not the DPI of the graphics object. They would never throw an exception. |
| | New Behavior | In the .NET Compact Framework 3.5, the DpiX and DpiY properties report the DPI of the graphics object. If the graphics object is disposed and these properties are queried, then these properties throw an ObjectDisposedException. |
System.Net | | Description | EndPoint methods, Create, Serialize and AddressFamily throw NotImplementedExceptions now | | Previous Behavior | These members would throw NotSupportedException if they were not implemented in a derived class. |
| | New Behavior | These members now throw NotImplementedException if they are not implemented in a derived class. |
System.Net | | Description | WebRequest and WebResponse unimplemented methods and properties now throw NotImplementedException | | Previous Behavior | Some members throw NotSupportedException if they are not implemented in a derived class. |
| | New Behavior | These members now throw NotImplementedException if they are not implemented in a derived class. |
System.Net.HttpWebResponse | | Description | HttpWebResponse.ResponseUri now reflects content of Content-Location header | | Previous Behavior | HttpWebResponse.ResponseUri would be set to the last request (after any redirects) that resulted in this response stream. |
| | New Behavior | HttpWebResponse.ResponseUri is set to the last request URI, and appended with an appropriate Content-Location header, when the server provides it. |
System.Net.ServicePoint.Address | | Description | ICertificatePolicy.CheckValidationResult now conforms with full .NET Framework behavior | | Previous Behavior | .NET Compact Framework would pass the ServicePoint representing the target server to this callback method. |
| New Behavior
(Version Coercion) | .NET Compact Framework will now pass the ServicePoint representing the proxy if one applies, or the target server if no proxy is being used. To find out information about the host being contacted when a proxy is in use, the WebRequest argument should be queried rather than the ServicePoint. This behavior conforms with the full .NET Framework. |
System.Net.Sockets.TcpClient.Dispose | | Description | Closing TcpClient closes the underlying network stream | | Previous Behavior | Disposing TcpClient previously did not close the underlying network stream. |
| | New Behavior | In the .NET Compact Framework version 3.5 and later, disposing TcpClient closes the underlying network stream. |
System.Reflection | | Description | Reflection sometimes throws the actual exception instead of TargetInvocationException | | Previous Behavior | In .NET Compact Framework 1.0 and .NET Compact Framework 2.0, reflection throws the actual exception thrown by the method that is being invoked. |
| | New Behavior | In .NET Compact Framework 3.5, reflection throws a TargetInvocationException and sets the InnerException property to the actual exception thrown by the method that is being invoked. |
System.Reflection | | Description | The .NET Compact Framework allows more permissive matching in Type.GetMethod() than the full . NET Framework does for BindingFlags.ExactBinding | | Previous Behavior | In .NET Compact Framework 1.0 and .NET Compact Framework 2.0, reflection is more permissive in matching functions with GetMethod when using the ExactBinding than the full .NET Framework is. It appears that if the .NET Compact Framework can perform a non-lossy conversion, it matches the function. For example, if class A has method M(double) and the .NET Compact Framework asks for M(int), Type.GetMethod(...) on the .NET Compact Framework returns M(double), but on the full .NET Framework it returns null. |
| | New Behavior | In .NET Compact Framework 3.5, Type.GetMethod(...) returns null if BindingFlags.ExactBinding is specified and the requested and existing method arguments do not match. For example, if class A has method M(double) and the .NET Compact Framework asks for M(int), Type.GetMethod(...) now returns null instead of M(double). |
System.Reflection.Assembly.GetType | | Description | Assembly.GetType returns incorrect values in the context of generics sometimes. | | Previous Behavior | .NET Compact Framework 2.0: This applies to nested generic types only. If an application created a closed generic type, for example, A.B<int> and then calls Assembly.GetType("A+B"), the Assembly.GetType() method will return a type object that represents the previously created closed generic type A.B<int>. |
| | New Behavior | .NET Compact Framework 3.5: If an application created a closed generic type, for example, A.B<int> and then calls Assembly.GetType("A+B"), the Assembly.GetType() method will return a type object that represents the open generic type A.B<T>. |
System.String.LastIndexOfAny | | Description | LastIndexOfAny called on an empty string throws an exception | | Previous Behavior | string.LastIndexOfAny(new char[] { ',' }) will throw an exception. |
| | New Behavior | In .NET Compact Framework version 3.5, string.LastIndexOfAny(new char[] { ',' }) returns -1. |
System.Text | | Description | UTF8Encoding and UnicodeEncoding error handling behavior has changed | | Previous Behavior | In .NET Compact Framework 1.0 and .NET Compact Framework 2.0 UTF8Encoding ignores invalid inputs as if they weren't there, except for unpaired surrogates which are treated like valid characters. UnicodeEncoding does not handle surrogates as special code points. |
| New Behavior
(Version Coercion) | In the .NET Compact Framework version 3.5, UTF8Encoding throws an exception on invalid inputs or replaces them with the fallback value 0xFFFD. UnicodeEncoding throws an exception on unpaired surrogates or replaces them with the fallback value 0xFFFD. Surrogates which span blocks are now remembered by decoders and encoders. |
System.Web.Services | | Description | Whitespace in received messages now treated as significant. | | Previous Behavior | SOAP messages read by a .NET Compact Framework client would be deserialized treating whitespace as insigificant, such that the element <str> </str> would be deserialized as the empty string rather than a string with a single space character in it. |
| New Behavior
(Version Coercion) | SOAP messages read by .NET Compact Framework are now deserialized with whitespace treated as significant to behave closer to how desktop treats messages. For instance, the element <str> </str> would be deserialized as the one character string " ". |
System.Web.Services.Protocols.SoapHeader.MustUnderstand | | Description | If MustUnderstand header is present and SoapHeaderAttribute with unknown headers is set on the web method we throw SoapHeaderException | | Previous Behavior | Exception thrown |
| | New Behavior | Exception only thrown if the SoapHeaderAttribute with unknown headers is NOT set on the WebMethod |
System.Windows.Forms.Form.Parent | | Description | Forms can no longer be parented. | | Previous Behavior | In .NET Compact Framework 1.0, forms could be parented to any other control that supported child controls.
In .NET Compact Framework 2.0, forms could be parented to any other form. |
| | New Behavior | In the .NET Compact Framework version 3.5, forms cannot be parented. |
System.Windows.Forms.Form.ShowDialog | | Description | Showing a modal dialog box no longer causes modeless dialog boxes to become disabled until all modal dialog boxes are dismissed. | | Previous Behavior | In .NET Compact Framework 1.0 and .NET Compact Framework 2.0, if there is an enabled modal dialog box active, and a modeless dialog box active, then showing another modal dialog box will cause the modeless dialog box to be disabled until all modal dialog boxes are closed. |
| | New Behavior | In .NET Compact Framework 3.5, if there is an enabled modal dialog box active and a modeless dialog box active, then showing another modal dialog box will cause previously active modeless and modal dialog boxes to become disabled until the second modal dialog box is closed. |
System.Windows.Forms.NumericUpDown.Value | | Description | NumericUpDown.Value returns the wrong value when assigned value greater than 0x7FFF | | Previous Behavior | In .NET Compact Framework 1 and .NET Compact Framework 2.0, platforms based on Windows CE did not support the UDM_SETPOS32 message, only the UDM_SETPOS message. SETPOS passes the value (POSition) of the up/down control in a 16-bit word of the LPARAM. Consequently, when the Value property of the managed control was set between 0x7FFF and 0xFFFF, values are erroneously treated as negative values, and values greater than 0xFFFF are truncated. Similarly, although the limits can be set to 32-bit integer values (using UDM_SETRANGE32) and end users can set or scroll the control to a value larger than a signed 16-bit integer could represent, only the UDM_GETPOS message is available to query the current value. Using GETPOS, the value is truncated to 16-bits and reported incorrectly to the Value property of the managed control. In addition, although the Value property (and other properties) of the NumericUpDown control is Decimal type, since the underlying native control uses signed 32-bit integers to keep track of the current minimum and maximum value, setting these properties to large Decimal values (larger than can be represented with 32-bit integers) causes an OverflowException to be thrown. |
| | New Behavior | In NET Compact Framework 3.5, setting Minimum, Maximum or Increment to a value that cannot be represented by a signed 32-bit integer throws an ArgumentException. On platforms that do not support UDM_GETPOS32 (those based on Windows CE 4.x and earlier), these properties are limited to the range of a signed 16-bit integers, and if you set them out of range it will result in an ArgumentException. This prevents the situation where the Value property returns the wrong value because it might be outside the range of a signed 16-bit integer. In backwards compatability mode, the .NET Compact Framework version 3.5 will not check the signed 16-bit range. However, it will use UDM_GETPOS32 to correctly report the value of the control in the Value property, which could result in a different return value from version 1 or 2 on older platforms (that is, when the control value was out of range of a signed 16-bit integer and was previously reported incorrectly from UDM_GETPOS). |
System.Windows.Forms.OpenFileDialog | | Description | OpenFileDialog fails without error in low memory conditions | | Previous Behavior | In the .NET Compact Framework 1.0 and .NET Compact Framework 2.0, if OpenFileDialog fails due to an inability to load a dll due to an an out of memory condition, the ShowDialog method returns DialogResult.Cancel. |
| | New Behavior | In .NET Compact Framework 3.5, if OpenFileDialog fails due to an inability to load a dll or due to an out of memory condition, the ShowDialog method throws an OutOfMemoryException. |
System.Windows.Forms.TextBox.TextChanged | | Description | The TextChanged event fires differently in various versions of the .NET Compact Framework runtime depending on whether or not the TextBox is parented. | | Previous Behavior | In .NET Compact Framework 1.0, a TextChanged event is triggered when the text is changed regardless of whether or not the TextBox is parented to another control.
In .NET Compact Framework 2.0, a TextChanged event is triggered when the text is changed only if the control has been parented to another control. |
| | New Behavior | In .NET Compact Framework 3.5, a TextChanged event is triggered when the text is changed regardless of whether or not the TextBox is parented to another control. |
System.Xml.Serialization.XmlSerializer | | Description | XmlSerializer requires all types to be serialized to be provided to constructor. | | Previous Behavior | The XmlSerializer would serialize types any type encountered at runtime during the serialization phase, regardless of types initially reflected over during XmlSerializer construction. |
| New Behavior
(Version Coercion) | The XmlSerializer throws an InvalidOperationException when it encounters an object during serialization whose runtime type was not given to the constructor or referenced by the static types that were provided to the constructor. |
System.Xml.Serialization.XmlSerializer | | Description | IXmlSerializable types are now instantiated even from xsi:nil='true' tags. | | Previous Behavior | .NET Compact Framework 2.0 and earlier would not instantiate classes implementing IXmlSerializable if the tag had an xsi:nil='true' attribute. |
| New Behavior
(Version Coercion) | .NET Compact Framework 3.5 will instantiate classes while deserializing a tag for that class regardless of whether xsi:nil='true' is present, giving the custom-serializing class a chance to deserialize any custom attributes from a non-.NET serializer. |
System.Xml.Serialization.XmlSerializer | | Description | XmlSerializer.CanSerialize returns false for extra types supplied in call to XmlSerializer constructor. | | Previous Behavior | CanSerialize returned true for the primary type, as well as the extra types supplied to the XmlSerializer constructor. |
| New Behavior
(Version Coercion) | CanSerialize returns true when the supplied XmlReader is positioned at the start tag of the primary type, and not for any other type. This behavior is consistent with desktop. |
System.Xml.Serialization.XmlSerializer | | Description | Namespaces of array elements belonging to arrays declared as "object" changed. | | Previous Behavior | When serializing a type with a member declared with type System.Object and assigned an array, the serialized elements of that array belonged to the same namespace as the parent array element. |
| New Behavior
(Version Coercion) | When serializing a type with a member declared with type System.Object and assigned an array, the serialized elements of that array take on the default namespace that the serializer was constructed with. This behavior is consistent with the desktop Framework. |
System.Xml.Serialization.XmlSerializer | | Description | XmlSerializer no longer allows [XmlArrayAttribute] on non array-like members of types. | | Previous Behavior | XmlSerializer would ignore or partially ignore properties set on XmlArrayAttribute for members that were not array-like (arrays, collections, enumerables) |
| New Behavior
(Version Coercion) | XmlSerializer now throws an InvalidOperationException at construction time when reflecting over types that inappropriately use XmlArrayAttribute. This behavior is consistent with the full .NET Framework. |
System.Xml.Serialization.XmlSerializer | | Description | XmlSerializer requires that array types encountered during serialization be declared. | | Previous Behavior | A member declared with type System.Object could be assigned an array and serialized without passing that array type as an extra type to the XmlSerializer. |
| New Behavior
(Version Coercion) | The XmlSerializer requires that all types to be serialized (including array types) be provided to the XmlSerializer constructor via the primary type argument, the extra types argument, or discoverable by reflection through one of the types provided in the arguments. |
System.Xml.Serialization.XmlSerializer | | Description | XmlSerializer only starts serialization with the primary type supplied to its constructor. | | Previous Behavior | XmlSerializer would allow any type it could recognize to be passed to the Serialize method. |
| New Behavior
(Version Coercion)
| An InvalidOperationException is now thrown whenever an object is passed to the Serialize method that cannot be cast to the primary type supplied to the XmlSerializer constructor. |
System.Xml.Serialization.XmlSerializer | | Description | For the XmlSerializer, no InvalidOperationException is thrown when XmlElement is used in conjunction with XmlArrayItem | | Previous Behavior | Several invalid combinations of XmlElementAttribute, XmlAttributeAttribute, XmlArrayAttribute, et al, are silently ignored by the .NET Compact Framework. |
| New Behavior
(Version Coercion) | In .NET Compact Framework 3.5, an InvalidOperationException is thrown in the XmlSerializer constructor when invalid combinations are reflected over, which is consistent with behavior in the full .NET Framework. |
System.Xml.Serialization.XmlSerializer | | Description | XmlSerializer applies namespace in XmlType attribute to root tag | | Previous Behavior | XmlTypeAttribute.Namespace is used for a serialized object's root tag namespace instead of XmlRootAttribute.Namespace. |
| New Behavior
(Version Coercion) | In .NET Compact Framework 3.5, XmlRootAttribute.Namespace is used to determine the serialized object's root tag namespace, which conforms to full .NET Framework behavior. |
System.Xml.Serialization.XmlSerializer | | Description | XmlSerializer does not throw an InvalidOperationException when deserializing an XmlElement with a changed name. | | Previous Behavior | When the XmlSerializer deserializes an object in which the root tag in the XML has the wrong tag name, deserialization occurs anyway. |
| New Behavior
(Version Coercion) | In .NET Compact Framework 3.5, the XmlSerializer now checks for the correct tag name before deserialization starts. This conforms to the full .NET Framework behavior. |
System.Xml.Serialization.XmlSerializer | | Description | Tag names assigned by the XmlSerializer for generics classes | | Previous Behavior | The XmlSerializer inserts a digit between the class name and the generic argument. For example, MyClass <int> gets the tag name MyClass1OfInt32. This was incompatible with the full .NET Framework. |
| | New Behavior | In .NET Compact Framework 3.5, the XmlSerializer assigns tag names to generics classes in a way that is consistent with the full .NET Framework behavior. For example, MyClass<int> gets the tag name MyClassOfInt32. |
System.Xml.Serialization.XmlSerializer | | Description | XmlSerializerNamespaces does not throw an InvalidOperationException for duplicate prefix namespace pairs when serializing to an XML document | | Previous Behavior | In .NET Compact Framework 2.0, no InvalidOperationException was thrown when a reserved XML namespace prefix was redefined by user code. |
| New Behavior
(Version Coercion) | In .NET Compact Framework 3.5, an InvalidOperationException is thrown when a reserved XML namespace prefix is redefined in user code, which conforms to behavior in the full .NET Framework. |
System.Xml.Serialization.XmlSerializer | | Description | Reflecting a class that has its value type set to null does not result in an InvalidOperation exception | | Previous Behavior | When the IsNullable property of SoapElementAttribute, XmlArrayAttribute, XmlArrayItemAttribute, XmlElementAttribute, or XmlRootAttribute was set to true for a non-nullable source, the .NET Compact Framework would not throw an InvalidOperationException during serialization. |
| New Behavior
(Version Coercion) | The same scenario using .NET Compact Framework 3.5 now throws an InvalidOperationException to conform with the full .NET Framework behavior. |
System.Xml.Serialization.XmlSerializer | | Description | XmlSerializer serializes object members in an order that more closely matches the declaration order where no order is explicitly defined | | Previous Behavior | XmlSerializer scrambles the order of XmlElements in a serialized object unless the Order property is set on XmlElementAttribute and similar attributes. |
| | New Behavior | XmlSerializer preserves the order in which members are reflected from serialized objects where the Order property is not explicitly set. Note that where element ordering is important, explicitly setting the Order property is still recommended on both the .NET Compact Framework and the full .NET Framework to guarantee proper serialization order across platforms and versions. |
System.Xml.Serialization.XmlSerializer | | Description | XmlSerializer will only start deserialization with the type given as the primary type | | Previous Behavior | XmlSerializer.Deserialize would begin deserialization when an XmlReader was positioned at any type provided to the XmlSerializer constructor. |
| New Behavior
(Version Coercion) | XmlSerializer.Deserialize will throw an InvalidOperationException when the given XmlReader is not positioned at the start element of the primary type passed to the serializer's constructor. |
System.Xml.XmlNode | | Description | XmlNode movements around DOM tree throw events differently | | Previous Behavior | When using XmlDocument's AppendChild, InsertBefore or InsertAfter methods to move a node from one location in the DOM to another, events would fire in Inserting, Removing, Removed, Inserted order. Also, some events would provide both OldParent and NewParent information while others would not. |
| New Behavior
(Version Coercion) | When using XmlDocument's AppendChild, InsertBefore or InsertAfter methods to move a node from one location in the DOM to another, events now fire in Removing, Removed, Inserting, Inserted order. Values provided as arguments to these event handlers are now consistent with desktop's, in that only OldParent OR NewParent is provided -- never both. |
System.Xml.XmlTextWriter.WriteEntityReference | | Description | XmlTextWriter.WriteEntityReference restores V1 behavior for V1 applications | | Previous Behavior | In .NET Compact Framework, XmlTextWriter.WriteEntityReference threw a NotSupportedException regardless of the .NET Compact Framework version the running app was built against. |
| New Behavior
(Version Coercion) | XmlTextWriter.WriteEntityReference now throws NotSupportedException for .NET Compact Framework 2.0 and .NET Compact Framework 3.5 applications, but provides .NET Compact Framework 1.0 implemented behavior for applications built with .NET Compact Framework 1.0. |
System.Xml.XmlTextWriter.WriteEntityReference.CloneNode | | Description | XmlEntityReference.CloneNode behavior restored for V1 applications | | Previous Behavior | XmlEntityReference.CloneNode returned null regardless of input or app version. |
| New Behavior
(Version Coercion) | XmlEntityReference.CloneNode returns a clone for applications built with .NET Compact Framework 1.0; returns null for applications built with .NET Compact Framework 2.0; and throws NotSupportedException for applications built with .NET Compact Framework 3.5. |
System.Uri | | Description | Uri class no longer compresses multiple slashes or backslashes found in a row (ported desktop QFE 4390) | | Previous Behavior | When passing a URI to the Uri constructor, any series of slashes that are not part of the scheme seperator would be condensed to one. For example, http://localhost/reportserver//foo//report would be changed to http://localhost/reportserver/foo/report |
| | New Behavior | When passing a URI to the Uri constructor, all series of slashes are preserved. For example, http://localhost/reportserver//foo//report will be unchanged (extra slashes are not removed). |
| |