Implementation Differences Between Silverlight and Silverlight for Windows Phone
This topic describes feature implementation differences between Silverlight on Windows Phone and Silverlight 4 on other platforms. This topic also describes some differences between Silverlight on Windows Phone OS 7.0 and Windows Phone OS 7.1.
The following topics also provide additional information about Silverlight for Windows Phone.
For a summarized list of supported and unsupported features, see Features Differences Between Silverlight and Silverlight for Windows Phone.
For detailed information about unsupported types and members, see Class Library Support for Windows Phone.
The following sections in this topic provide detailed information about Silverlight for Windows Phone.
Multitouch and Manipulation Events
Silverlight Extensions for Windows Phone
For information about supported and unsupported controls, see Controls in Silverlight for Windows Phone.
AsyncCallback callback = new AsyncCallback(result); callback.BeginInvoke();
Some exceptions are different in Silverlight for Windows Phone when using delegates:
Constrained execution regions (CERs) are not supported in Silverlight for Windows Phone.
For information on supported fonts in Silverlight for Windows Phone, see Fonts in Silverlight for Windows Phone.
When you specify a generic type you can specify a maximum of 64 generic type parameters. If you are using generics types with LINQ to SQL, you can use nested queries to work around this limitation.
The graphics threading architecture in Silverlight for Windows Phone is optimized for devices. For information on the threading architecture and how to improve graphics performance, see Graphics in Silverlight for Windows Phone.
Custom pixel shaders are not supported, so the PixelShader type is not supported.
For additional information about graphics and animation in Silverlight, see the following topics.
Controls that are supported on Windows Phone are gesture-aware, and support gestures such as tap, double-tap, hold, pan, and flick.
For additional information on input differences between Silverlight on Windows and Windows Phone, see Input in Silverlight for Windows Phone.
For information on using manipulation events to respond to touch input, see How to: Handle Manipulation Events.
For information on platform differences associated with I/O streams, see Streams in this topic.
Isolated storage allows applications to store data in a virtual file system. The data is completely isolated from other system components. This prevents unauthorized access and data corruption by components other than the application that is storing the data.
As in Silverlight on Windows, the data is automatically deleted when you uninstall the associated application on the Windows Phone. The data is retained in other scenarios, including a device or application update, or a device restart.
Isolated storage on Windows Phone does not enforce quotas to restrict the size of isolated storage for Silverlight-based applications. The default quota size of 1 MB does not apply.
Implementation differences between Silverlight on Windows Phone and Silverlight on Windows include the following:
Isolated storage on Windows Phone does not include the concept of a site; therefore, GetUserStoreForSite is not supported.
IncreaseQuotaTo throws an exception.
When you call BeginRead or BeginWrite in a Windows Phone application, the operation is executed synchronously. If you need to write a large amount of data and do not want to interrupt the UI thread, you can create a new thread and perform the operation on that thread.
In the IsolatedStorageFileStream class constructor, FileShare.Delete and FileShare.Inheritable are not supported because of a platform limitation. Passing a value of Delete will cause a IsolatedStorageException.
The default quota size returned to an application is MAXLONG.
When using isolated storage, strings that contain wild card characters or regular expression are not supported when passed as input if the string also contains a filename or a directory name.
For information about isolated storage in Silverlight, see the following topics:
LINQ query providers for custom data sources are not supported in Silverlight for Windows Phone.
LINQ to XML
The following limitations apply to LINQ to XML support:
The constructor for the XmlSerializer object throws an InvalidOperationException if the XmlSerializer object is initialized with a type parameter that contains two XElement members and both are marked with the XmlAnyElementAttribute.
LambdaExpression.Compile is not supported in Windows Phone SDK.
Silverlight for Windows Phone throws an exception while trying to create a new object using a lambda expression that targets expression trees. For example,
Expression <D1> d = () => new N(); will compile, but fails at runtime.
Support for globalization is based is based on the cultures and regions supported by the underlying platform. For additional information, see Creating Globally Aware Applications. For information on culture names supported on Windows Phone, see Globalization and Localization Overview for Windows Phone.
Some of the types and members that support localization behave differently on Silverlight for Windows Phone, as follows:
A custom culture returns standard formatting when custom formatting is expected. For example, 31/08/2006 12:30:15 Afternoon! returns as 8/31/06 12:30:15 PM.
You cannot use a neutral culture in formatting and parsing; therefore you cannot set a neutral culture as the thread's current culture.
DateTimeFormatInfo.ShortTimePattern values do not change when the clock is set to 24 hours. The property values should become "h:mm" but remain "h:mm tt" where tt is AM or PM.
ToString() does not return the expected value for a null format and Invariant Culture.
DateTimeFormatInfo.GetEra returns -1 for the fr-FR culture.
new CultureInfo(“fr”).DateTimeFormat.AMDesignator throws a NotSupportedException.
DateTimeFormatInfo.GetEraName method returns incorrect values in some cases. For example, the fr-FR localization string DC is returned when A.D is expected.
DateTime.ToString does not return the correct string for Russian dates. For example, 15.Июнь.2000 is returned instead of 15.июня.2000.
System.DateTime.Now.Millisecond.ToString always returns zero on the Windows Phone Emulator.
Double.ToString does not return the correct string containing comma delimiters between group digits when a custom format is used.
ResourceManager.GetSatelliteContractVersion returns a random version number instead of the expected value.
String comparison operations for strings containing trigraphs may not work as expected for cultures where trigraphs are used, such as "dzh" in the culture hu-HU. For example, IndexOf(String, String, CompareOptions) and IsSuffix(String, String, CompareOptions) may return an incorrect result.
The constructor, ResourceManager(String, Assembly, Type), throws NotSupportedException when the usingResourceSet parameter is null.
ResourceManager.GetObject does not throw an exception when the object is missing in the resource file.
Some localization exceptions thrown by applications are different in Silverlight for Windows Phone:
If you pass an invalid culture for the satellite assembly in Assembly.GetSatelliteAssembly(CultureInfo), the method throws a FileNotFoundException on Windows Phone. Also, if you pass InvariantCulture, the Assembly.GetSatelliteAssembly(CultureInfo) method returns an en-US satellite assembly instead of throwing a FileNotFoundException.
If you set CultureInfo("fr").NumberFormat.CurrencySymbol to "USD", it throws NotSupportedException.
Serializing Custom attributes on Estonian culture (et-EE) culture does not work properly.
For information about media implementation differences between Silverlight on Windows and Silverlight on Windows Phone, see Media in Silverlight for Windows Phone.
Multitouch and Manipulation Events
To enable multitouch and manipulation events, Silverlight for Windows Phone supports types, members, and events that are not present in Silverlight 4. For additional information, see How to: Handle Manipulation Events.
For information on input differences between Silverlight on Windows and Windows Phone, see Input in Silverlight for Windows Phone.
Silverlight for Windows Phone provides a different page navigation model than Silverlight on Windows. The Frame and Page classes are not supported. The implementation of these classes and some navigation-related events such as the FragmentNavigation event, are provided in the Microsoft.Phone assembly instead of the System.Windows.Controls.Navigation assembly. For additional information, see the Frame and Page Navigation topic in Windows Phone Development.
In Windows Phone OS 7.1, if you use the NavigationEventArgs(Object, Uri) constructor to create a NavigationEventArgs and pass null for the uri parameter, when you later access the Uri property, it will be an empty Uri.
For information about networking implementation differences between Silverlight on Windows and Silverlight on Windows Phone, see Networking in Silverlight for Windows Phone.
On Windows Phone, Environment.CurrentDirectory and Environment.GetFolderPath have a SecurityCriticalAttribute attribute, because Silverlight for Windows Phone is based on Silverlight. This attribute restricts this member to internal use. Application code that uses this member throws a MethodAccessException.
Some path-related exceptions thrown by applications are different in Silverlight for Windows Phone:
If you pass an invalid path in GetDirectoryName, the method does not throw an exception. For example, System.IO.Path.GetDirectoryName(@"D:\\temp\\ .") returns "D:\temp" instead of throwing an exception.
GetDirectoryName does not throw any exception when the source path is longer than the system-defined maximum path length.
GetPathRoot returns an empty string when the input is prefixed with whitespace.
System.IO.Path.GetPathRoot(String.Empty) returns a null string instead of throwing an ArgumentException.
System.IO.Path.GetPathRoot(@":hello") returns a null string instead of throwing an ArgumentException.
Silverlight for Windows Phone supports a composition thread for certain graphics animation and access to the graphics processing unit (GPU). For information on optimizing graphics performance using this architecture, see Performance Considerations in Applications for Windows Phone and Graphics in Silverlight for Windows Phone.
The frame rate counter in Silverlight for Windows Phone is different than the frame rate counter on Windows. For additional information, see Graphics in Silverlight for Windows Phone.
To optimize XAML code when applying multiple transformations, Silverlight for Windows Phone supports CompositeTransform.
For Silverlight performance tips, see Performance Tips.
Reflection implementation differences between Silverlight on Windows and Windows Phone are as follows:
Reflection is always case-sensitive. If you attempt to perform a case-insensitive type search by calling the Type.GetType(String, Boolean, Boolean) method and passing true for the ignoreCase parameter, a NotSupportedException is thrown.
Some types and members are not supported in Silverlight for Windows Phone. For a list of unsupported methods, see Class Library Support for Windows Phone.
Open generics, which are generic types or methods that do not have instantiable types substituted for all its type parameters, are not supported in Silverlight for Windows Phone. The following operations are exceptions to this and are supported:
Behavior and functional differences exist between the binder implementation in Silverlight and Silverlight for Windows Phone.
GetPublicKeyToken returns null instead of byte for a byte PKT or for an assembly name containing PublicKeyToken=null.
AssemblyName.FullName does not return PublicKeyToken information by default. Silverlight for Windows Phone only provides the assembly name. You must use individual methods to compare the culture, version, and PKT information.
For the declaringType parameter, GetMethodFromHandle(RuntimeMethodHandle, RuntimeTypeHandle) uses RuntimeMethodHandle instead of RuntimeTypeHandle.
The equality (==) operator for two equal MethodInfo objects does not return true in Silverlight for Windows Phone.
FieldInfo.ToString() returns System.Boolean instead of Boolean when it points to a bool.
GetValue(Object, BindingFlags, Binder, array<Object, CultureInfo) throws ArgumentException when the index parameter is a string value and binder is not the default binder.
In Silverlight for Windows Phone, the ignoreCase parameter is not supported on Type.GetType(String, Boolean, Boolean). You must use case-sensitive type names.
In Silverlight for Windows Phone, DefaultValue returns null.
Type.GetMember method does not return any public members with the specified name if the name string is a regular expression.
The return value for Type.AssemblyQualifiedName is not the same between Silverlight for Windows Phone and . For example, the return value for AssemblyQualifiedName on Silverlight for Windows Phone might look like this: MyType, MyAssembly, Version=18.104.22.168, Culture=neutral, PublicKeyToken=b17a5c561934e089. In , the equivalent return value might look like this: MyType, MyAssembly, Version=22.214.171.124, Culture=neutral, PublicKeyToken=B17A5C561934E089.
Some exceptions thrown by reflection-based applications are different in Silverlight for Windows Phone:
LoadFrom fails when you try to load a file that is not a valid assembly. This behavior is by design; the failure occurs during metadata validation to prevent loading of a corrupt image.
If you pass an invalid culture for the satellite assembly in Assembly.GetSatelliteAssembly(CultureInfo), the method throws FileLoadException on Windows, but it throws a FileNotFoundException on Windows Phone.
MethodBase.GetMethodFromHandle does not throw any exception when an invalid handle is passed as input. Instead, it returns null.
When the current type object contains open type parameters, Type.InvokeMember(String, BindingFlags, Binder, Object, array<Object) throws NotSupportedException instead of InvalidOperationException.
Some attribute constructor arguments and property values can cause Type.GetCustomAttributes to fail.
Type.GetConstructor(BindingFlags, Binder, array<Type, array<ParameterModifier) throws ArgumentNullException when no ParameterModifier types are specified (NULL is passed). On Windows, no exception is thrown.
Silverlight for Windows Phone runs on the .NET Compact Framework. Applications written for previous versions of Windows Phone or for .NET Compact Framework 3.5 or earlier are not supported on Windows Phone.
Windows Phone applications typically must support different screen resolutions for orientation changes. For application design tips, see Designing a Flexible User Interface.
The following differences apply to X509 certificates:
To enable you to set the software input panel (SIP) on a TextBox control, Silverlight for Windows supports several types and members that are not present in Silverlight. For more information, see How to: Specify On-Screen Keyboard Layout for a TextBox.
Silverlight Extensions for Windows Phone
For additional features that are specific to Windows Phone development, see the Class Library Reference for Windows Phone. These features are included in the Windows Phone SDK.
The following differences apply to the use of streams:
StreamWriter.Write and StreamReader.Read may throw IndexOutOfRangeException if the stream state becomes corrupted. On Silverlight for Windows Phone, the stream state may become corrupted if multiple threads read from or write to a stream object without using synchronization.
A StringBuilder object can allocate more memory as needed as characters are added to the object. The amount of memory allocated is implementation-specific, and an OutOfMemoryException is thrown if the amount of memory required is not available. If an alternative to StringBuilder is needed, open a MemoryStream and write strings to the memory stream instead of using the StringBuilder class.
If you call Replace when a null character exists in the string, the new string will be truncated at the first null character.
The String.IndexOf method returns incorrect output when the string contains Unicode characters.
The String.LastIndexOf(String, Int32, StringComparison) method returns incorrect values when the string contains Unicode characters.
The StartsWith(String, StringComparison) method returns incorrect values when the string contains Unicode characters.
Unlike Silverlight, Silverlight for Windows Phone splits animation work on two different threads for better performance on devices. For additional information, see Graphics in Silverlight for Windows Phone.
Array.Sort(Array) is not thread safe.
ThreadStaticAttribute is not used by the Silverlight for Windows Phone.
WaitAll is not supported in Silverlight for Windows Phone.
The 64-bit members of the Interlocked class are present but not supported.
In Silverlight for Windows Phone, the HttpUtility class is in the System.Net namespace. On Windows, this class is in the System.Windows.Browser namespace, which is an unsupported namespace on Windows Phone.
LocalPath does not convert the forward slash (/) to a backslash (\). This is because file-based URIs (URIs of the form file://) are not allowed. Paths returned are relative paths.
To optimize XAML when you are applying multiple transformations, Silverlight for Windows Phone supports CompositeTransform.
Parse is not supported in Silverlight for Windows Phone because Silverlight for Windows Phone does not support document type definitions (DTDs). The application throws a NotSupportedException when it encounters a DTD string in XML. To parse DTDs, an application must either implement this feature or use XML schemas.
The following differences also apply to Silverlight for Windows Phone:
Using System.Xml.Serialization.XmlSerializer to serialize and deserialize classes associated with LINQ to XML such as XElement and XName is not supported.
Wrapping a custom reader is allowed in Silverlight for Windows Phone. That is, you can create a custom reader with your own implementations of the required functions, and then pass the custom reader as input to XmlReader.Create(XmlReader, XmlReaderSettings).
Some XML exceptions thrown by applications are different in Silverlight for Windows Phone:
For DataContractSerializer class constructors that include an IEnumerable parameter, if the type passed in the knownTypes parameter is an implementation of the interface specified by the type parameter, and the interface is not public, Silverlight for Windows Phone throws a MessageSecurityException. On other platforms, serialization occurs with no exception thrown.
Message.ToString() shows different behavior on Windows Phone. Message.ToString() does not show XML version information in Silverlight for Windows Phone.
XNA Framework for Windows Phone and Silverlight for Windows Phone are dependent on .NET Compact Framework for base class library support. Most of the supported types and members are the same. For additional information, see XNA Framework and Silverlight.
Additional implementation differences in APIs are as follows:
When you try to create circular nested generic classes, a TargetInvocationException is thrown. You cannot create a circular nested generic class in Silverlight for Windows Phone.
Classes in the System.Collections namespace do not throw ArgumentNullException when a null parameter is passed to the constructor. For example, Dictionary<object, object>.ValueCollection valueCollect = new Dictionary<object, object>.ValueCollection(null) does not throw ArgumentNullException.
GetHashCode returns equal values for different methods of the same class.
GetHashCode returns zero for some user-defined structs in Silverlight for Windows Phone, but non-zero values in .NET Framework.
Decimal.Parse returns an invalid decimal value when exponents are used for values near zero. On Windows, the method returns zero. For example, for the values 0E-50 and 10900E-512, an invalid decimal value is returned instead of zero.
The value of Math.Sin(Math.PI/2) is 0.99999999999999989. The value on Windows is 1.
Some methods throw different exceptions in Silverlight applications on Windows versus Windows Phone. The following information describes this behavior on Windows.
Silverlight for Windows Phone throws an exception when deriving a class from Dictionary<TKey, TValue> where the key parameter is an enumeration.
If your application attempts to invoke a non-existing method of a type, or tries to invoke a method that has ambiguity, Silverlight for Windows Phone throws AmbiguousMatchException.
ArgumentException displays the message Argument Exception instead of Exception of type 'System.ArgumentException'. Similarly, ArithmeticException displays Arithmetic Exception instead of the string that is thrown on Windows.
The display message for MissingMethodException is incorrect.