Ensuring that your JavaScript Silverlight applications work with Silverlight 2

Technorati Tags: Silverlight

del.icio.us Tags: Silverlight

While Silverlight 2 was designed to be fully backwards compatible with Silverlight 1.0, there is a chance that you may have some JavaScript code that behaves differently than expected when your application is accessed by somebody with the Silverlight 2 runtime.

There are a number of potential reasons for this, for example we may be providing a different status report for an exception, or, we have fixed a bug in the framework, and a workaround that you would have built to mitigate this bug no longer works.

These issues will generally only occur in very specific situations and will usually not lead to an application failure.

The issues are here:

Exceptions Reported instead of silent failures on Image URLs.

In Silverlight 1, if your application had a state where you were loading an image from an invalid URL it would fail silently, and no exception would be raised. Silverlight 2 raises an exception in this case, so if you wrote your code without an exception handler for this scenario, your end users would see a Silverlight error dialog if they are using Silverlight 2. Other than that, your application would behave in the same way (i.e. it would be unable to load the image from the invalid URL)

Action: Ensure that you are using exception handling before reading an image from a URL.

Change of behavior when Double Encoding Image URLs

Silverlight 1 was unable to handle some characters in Image URLs, and as such double encoding was necessary. This has been fixed in Silverlight 2, so if you have hard coded double-encoded URLs in your application, you may have some invalid URL errors thrown (see above)

Action: Remove any double-encoded hard coded URLs, and replace with normal URLs. Ensure that you are using exception handling before reading an image from a URL.

Change of behavior when reading XAML with relative path specifiers

This only applies when you specify the XAML on the Silverlight plug-in object. If you specified the XAML location using relative path specifiers (i.e. https://mydomain.com/app/../location.xaml), Silverlight 1.0 would resolve the URL. Silverlight 2 does not, and the full URL needs to be specified.

Action: Ensure that you are not using relative path specifiers on your XAML. Ensure that you are using exception handling on the plugin.

Exceptions Reported instead of silent failures on invalid XAML

When using createFromXAML to load XAML into your render tree at runtime, Silverlight 1.0 was forgiving of invalid XAML where you had a property at the root element of the XAML string that you are parsing. Silverlight 2 will throw and exception in this case.

Additionally XAML properties that were invalid would fail silently in Silverlight 1. If you had, for example, the following XAML: <TextBlock><Canvas.RenderTransform>…</Canvas.RenderTransform></TextBlock>

Silverlight 1.0 would be forgiving of this error, but Silverlight 2 will throw an exception.

Action: Ensure that you are using exception handling. If your XAML throws any exceptions due to these invalid properties you will need to fix your XAML.

Null reported instead of success on searching some XAML

When using findName() to find a XAML element, in Silverlight 1.0, in the case of a Storyboard, if you searched for a transform (example <Canvas.RenderTransform><ScaleTransform.ScaleX>), you would receive a positive result. However, this is inconsistent, and in Silverlight 2, you will receive ‘null’ as results of this search.

Action: Make sure your object is named and search for it by name instead of property path.

Exception on specific Text Wrapping property instead of silent failure

When using a TextBlock, Silverlight 1.0 mapped the ‘WrapWithOverflow’ setting to ‘Wrap’ on the TextWrapping property when it hit it, and as such this invalid property did not cause an exception. Silverlight 2 does not have this behavior, so the XAML will not parse and an exception will be thrown.

Action: Replace instances of the ‘WrapWithOverFlow’ setting with ‘Wrap’.

Line breaking differences on TextBlock

In some cases, a TextBlock would wrap text if not enough horizontal space was provided, despite the fact that it was not instructed to do so through property settings. This has been fixed in Silverlight 2, and as such you may see some places where your text is not wrapping where it did previously.

Action: If your TextBlocks look different with Silverlight 2 than they did with 1.0 this is the cause. You’ll need to edit your XAML to get the desired results.

Different handling of markers in an ASX file

In Silverlight 1, only markers that were within the duration specified in an ASX would be visible. In Silverlight 2, all markers are visible, so if you have an application that uses markers, and in particular pre-reads these markers, you may see some slightly different behavior.

Action: If you are pre-reading markers, and are receiving markers that are outside of your expected time range, you will need to truncate them manually.