Question

Way back when I built an internal site for a customer using silverlight 2. They've been happy with it and I've barely had to touch it. Is the expectation that this site will always work? What I'm afraid of is suddenly getting a call years from now that the users installed silverlight X and now it's broken and I'm going to have to convert it immediately past Y versions of Silverlight to get the site back up, and I don't even do Silverlight anymore.

I already went through this once when it went from 2 beta to 2 release and and scrambling to fix all the breaking changes and get the site back up. It wasn't as big a deal then as we were in beta anyway.

I could upgrade now but it would be really tough to go back to the customer and ask for money to do an upgrade when they are happy now and will see no noticeable benefit from staying current. Additionally there are some third party controls that would have to be licensed again.

So I guess what I'm asking is there a known end of life? Or do we just play it by ear?

Was it helpful?

Solution

Based on the Silverlight Support Lifecycle Policy, it looks like official support for Silverlight 2 has already ended (as of October 12, 2010). However, some other documents (mostly listed at this SO question) give the impression that Silverlight apps are binary backwards-compatible through a sort of Silverlight "quirks mode," so as long as you're not changing your Silverlight app and the policy doesn't change, the app should work indefinitely.

OTHER TIPS

The folks at MS have so far done a reasonably good job of maintaining backwards compatibility between Silverlight releases. But there have been some significant changes, and depending on what your app does, what features it uses, and what bugs in the runtime that it takes advantage of, it may or may not continue to run cleanly on future versions of the runtime. MS gives some good examples of the breaking changes between Silverlight 3 and Silverlight 4 here.

One example of many: Silverlight 4 introduces a new "Watermark" property on the Textbox class. It's possible that a Silverlight 2 or Silverlight 3 application subclassed the Textbox class, and added their own Watermark property. References in XAML to that Watermark property could thus throw an AmbiguousMatchException when executed on a Silverlight 3 or Silverlight 4 runtime.

Presumably there will be more changes of this sort as MS moves to SL5 and then SL6, and so forth: and their dev team will stop worrying quite so much about breaking SL2 applications. A change that introduces a really cool feature but breaks some reasonable portion of SL2 applications would presumably be unacceptable in SL5, but maybe not in SL6 or SL7.

My recommendation in your specific situation would be to let your customer know about the possibility of future issues now, so that they have a chance to make a decision about it when it's not an emergency.

Take it easy :) It would allways work.. Silverlight have 100% backward compatibility for EVERY major version!

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top