Backward Compatibility with Silverlight 4 applications
| Comments- | Posted in
- silverlight
- wpf
- xaml
- ria
- riaservices
Each release of Silverlight it is the goal to make sure existing Silverlight applications continue to work. Since I think what this means causes some confusion I’m going to do my best to explain what we mean by this.
Silverlight 3 application working with Silverlight 4
Okay, scenario 1 is I have a Silverlight 3 application (XAP), will that still work as-is in Silverlight 4?
Yes, this is the situation we refer to as backward compatibility. What this means is that existing compiled XAPs under previous versions should continue to work as-is even if your users have a later version of Silverlight installed on their machine.
An example would be someone like Netflix. If you are already a Netflix instant watch user with their Silverlight application, then you’ve been watching movies fine on your computer for a while. If you go and download Silverlight 4 today, this should not change, even though their player is Silverlight 3. From the docs:
The Silverlight team wanted to fix a number of Silverlight 3 bugs in Silverlight 4. However, by fixing some of these bugs, it is possible that some existing Silverlight 3 applications would break. In order to avoid this, the Silverlight team addressed these potentially problematic changes by creating a "quirks mode" for runtime behavior. A quirks mode change is a case where the Silverlight 4 runtime will branch its behavior if the runtime detects that the application is targeting Silverlight 3. In this way, Silverlight 4 is made "bug compatible" as a runtime. However, the noted quirks mode behavior may need to be revisited if you recompile your application for Silverlight 4.
The above scenario (previous version Silverlight apps running under their version mode) is often referred to as “quirks mode.”
Silverlight 3 CODE recompiled as Silverlight 4 app
Next scenario is I opened my Silverlight 3 code project and compiled as Silverlight 4 and now it doesn’t work!? You said backward compatible!!!
This is where breaking changes come into play. Breaking changes range from anything from security fixes to bug fixes to correcting behavior that we wanted to change. We try at all costs to avoid breaking changes, but sometimes they are unavoidable to progress and make things right. When we can’t avoid them, we do our best to ensure that quirks mode (described above) works as customers expect.
For Silverlight 4, there are some breaking changes from 3->4 that developers should be aware of. These are all documented on MSDN here. Here is a point list of a few of them:
- XAML Parsing AmbiguousMatchException when application property conflicts with new Silverlight 4 property
- Toggling full screen mode reruns hit testing
- Shared BitmapImage resources
- DRM on cients with FAT32
The document explains the scenarios as well as what to do, if applicable.
Hopefully this helps understand a few things. If you find that your compiled Silverlight 3 XAP is not running correctly when rendered in a Silverlight 4 plugin environment, please let us know on the forums with as much detail as possible (i.e., “it doesn’t work” isn’t enough).
Please enjoy some of these other recent posts...
Comments