We Are GAP Mobilize
Free Assessment Tool

Getting off Microsoft Silverlight for good

by John Browne, on Jan 26, 2021 5:00:00 AM

Let's talk Silverlight--specifically how the heck do you get off it without pulling all your hair out?

Well, because Silverlight is SO old, perhaps we need a brief refresher before we get to the expulsion stage. (Don't need a refresher? Feel free to skip ahead, just like you did in the 2nd grade reading circle. Yeah, you.)


A Brief History of Time Silverlight

If you were born the same year as Silverlight (2007), you'd be in middle school now, unless you're a dog, in which case you're feeling the years. And if you're Silverlight, you're way past your sell-by date. 

Back in 2007, the Internet was a hollow shell of what it is today. If you wanted any kind of interesting content, your web devs would write some Adobe Flash code so you could have dancing kittens on your web page, or, to the infinite annoyance of basically everyone, a video that always played when you loaded or refreshed a page, regardless of how many times you had already seen the @#$% thing. Microsoft--apparently jealous that Macromedia/Adobe had found a way to annoy people that they hadn't--gathered together some of their best and brightest and said, "Let's do a Flash thingie, but, you know, incompatible with everything else." 


Thus was born Silverlight, which, in a spirit of openness, used a Microsoft programming language, Microsoft markup language, and Microsoft visual designer. And being Microsoft, many people decided to jump on this particular band wagon fully knowing that the odds were that Microsoft would--as they had so many times in the past--eventually drive it off a cliff, killing all on board. 

Like ABBA and Pet Rocks, Silverlight had an exciting but brief encounter with fame and glory. In 2008, NBC used it to stream the summer Olympics and then, having not learned their lesson, again in 2010 to stream the Winter Olympics in Vancouver, CA. Following on this triumph of pretending that free TV didn't exist, by 2011 people were already talking about the death of Silverlight. Microsoft, following a playbook they had made famous with tools like MFC and ATL, let their customers twist in the wind until 2015 when they finally announced that yeah, we've moved on, sorry! Today (Jan 2021) Silverlight is only available on IE 11 on Windows (no MacOS browser can run it). And on Oct. 12, 2021, all remaining support goes poof. Fortunately as of this writing the number of web sites still using the Three Horsemen of the Plug-in Apocalypse (Flash, Java, and Silverlight) is close to zero.

(Incidentally the reason Microsoft dropped support for Silverlight was it wouldn't run in the Windows 8 Metro-style browser. Remember Windows 8 and Metro? You see what I did there, right?)

Control freaks


When Microsoft released ActiveX, there was a gold rush of outside software developers creating new UI controls for Visual Basic integration. And Silverlight followed the same trend, spawning a rash of new and existing control vendors in a rush to market with sexy user interface widgets. This webpage lists no less than 16 vendors with control collections plus several open source projects. 

Silverlight introduced a lot of developers to a new way to design and think about user interfaces. Drawing on the work done for the Windows Presentation Foundation in 2006, Silverlight adopted the Extensible Application Markup Language (XAML) as a mechanism to separate the presentation of an application (that is, what it looks like) from the business logic. Prior to that, development systems like Visual Basic or frameworks like Windows Forms tightly coupled the user interface (presentation) with the business logic. Loosely coupled systems can render a presentation suitable for the device that the application is running on, whether a desktop computer or a browser. 

To create a UI in Silverlight, the developer had to create two files: a XAML file to define the visual elements, and a C# file to handle events on those elements. For example, here's the XAML for the OK and Cancel buttons in a Microsoft sample Silverlight app:

<Button x:Name="CancelButton" Content="Cancel" Click="CancelButton_Click" Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,0,0" Grid.Row="1" />
        <Button x:Name="OKButton" Content="OK" Click="OKButton_Click" Width="75" Height="23" HorizontalAlignment="Right" Margin="0,12,79,0" Grid.Row="1" />


If you're unfamiliar with XAML you will probably immediately see how similar it looks to XML, and even a passing resemblance to its cousin HTML. The concept is pretty straightforward: define an object inside some delimiters like <Button></Button> and then set properties (Name, Height, Content, etc.) for that object. I didn't show all the code, but the </Grid> termination at the end tells us these buttons were nested inside a Grid object, which in turn is set on a ChildWindow object. 

But along with the XAML code (which defines the UI elements), there's C# code to handle what happens in the UI:

 private void OKButton_Click(object sender, RoutedEventArgs e)
            this.DialogResult = true;

        private void CancelButton_Click(object sender, RoutedEventArgs e)
            NewEmployee = null;
            this.DialogResult = false;


That code is pretty self-explanatory, dealing with either an OK button (commit) or cancel button (bail out!). 

Where do we go now?

Ok, let's assume you are sitting on some Silverlight code--maybe you wrote it or maybe you inherited it, but either way you have to do something with it. Let's review some options:

  • Kick the can down the road. It's not as if the app will stop working on Oct. 13, 2021. Realistically, IE 11 will still be available and Silverlight will continue to run inside that browser. That's exactly the situation today (January 2021). If you work in any kind of industry with regulatory requirements around IT governance, you may be out of compliance by running out-of-vendor-support software. You also may be exposing your organization to malware vulnerabilities after Microsoft stops issuing patches and updates.
  • Retire: perhaps the app isn't consequential, and so you can shelve it and use something else, like Office or Google Docs. Or an abacus.
  • Rewrite from scratch: Always an option (not necessarily a good one) for legacy software, but if your app is largish, statistically you will probably miss your deadlines, blow the budget, get bogged down in requirements creep, and seriously start questioning your life choices.
  • Rewrite with Blazor: For Silverlight web apps, this is Microsoft's recommended approach. Blazor uses C# running on the browser (using WebAssembly) rather than on the server, so you can reuse a lot of your existing client-side C# code. The UI elements are built with HTML and CSS (not JavaScript). Blazor is still pretty new, it's YAMI (Yet Another Microsoft Idea) which may be a red flag to some, and it's still a work in progress.
  • Migrate to Angular: This is the approach we are pursuing. The client-side C# code is converted to TypeScript (which allows for richer semantics than JavaScript before transpiling), and the UI elements are converted to JavaScript on top of the Angular framework. JavaScript and Angular--along with HTML and CSS--are well known established approaches to building rich, responsive web applications, which is why we chose them.

Migrating Third Party Silverlight Controls to Angular

This is, as they say, the tricky bit. Control vendors like Infragistics and Progress/Telerik sold libraries of Silverlight controls which were quite popular and are found in may existing Silverlight applications. We've recently partnered with Infragistics to get their Silverlight UI controls converted to HTML and Angular. 


As the diagram above shows, the Mobilize.Net Silverlight migration tool converts the XAML to JavaScript and the C# event logic to Typescript. This is a particularly interesting problem since C# is a richer language than Typescript, which itself is just a transpiler for JavaScript. Our team has tackled C# semantic elements like interfaces and generics and successfully converted them to Typescript.

Currently the tooling is in internal beta and is being used on actual customer projects. If you have Silverlight web apps and want to learn more about our approach, you can download and run our new Silverlight code assessment tool. For help on migrating your Silverlight code, drop us a line at info@mobilize.net for more information.

Topics:application migrationSilverlight


Subscribe to Mobilize.Net Blog