Migrating from Silverlight is neither easy nor fun, but there are ways to reduce the pain. In this post we'll discuss your best options for migrating from Silverlight, and their associated costs and benefits.
You have several choices when it comes to migrating away from Silverlight—probably more than you realize. None of those options are perfect so there are trade-offs you’ll have to make.
Note: This post is part of a series on options for leaving Silverlight as it approaches its end of life. Check out these posts for more:
If you still have Silverlight applications around, it may be because you haven’t seen the need to make any changes to those applications. Or, it may be that you’ve been avoiding the problem because you recognize the amount of work required to recreate those applications. Well, you’re not wrong: Moving from Silverlight to any other platform isn’t going to be a trivial task. I’m not here to tell you there’s a “no effort/no cost” solution. But, as Silverlight reaches its end of life on October 12, 2021, recreating those applications may be becoming unavoidable for you, no matter how much work is involved.
There are ways to reduce the pain, however.
Assuming you want to stick with Microsoft technologies, you’ll want to move to .NET Core as “the current platform with the longest future” (no sense recreating the “abandoned tech” problem you’re facing now). What will limit your ability to move to .NET Core is the number of .NET Framework libraries your application references. For each of those libraries, you’ll need to assess whether a .NET Core replacement exists and, if it doesn’t, how much work is required to move to equivalent functionality.
If the cost of going to .NET Core is high, then sticking with .NET Framework isn’t a terrible choice. The latest/greatest version is Framework .NET 4.8 and (as of this posting) it had no end-of-life date.
But, of course, the elephant in this particular virtual living room is XAML. You don’t have to abandon XAML—there are, at least, two good options that will let you keep some of your XAML. However, part of the problem you’ll face in keeping your XAML is that there are several different versions out there:
This means that, even if you want to keep your XAML, you’re going to have to deal with some conversion effort. If you’re going to have to make some conversion effort, you should (at least) be considering converting your XAML to some other format. The obvious choice is HTML, if only because your users have been getting your Silverlight applications through a web browser.
Converting XAML to HTML is, clearly, not a trivial task. You can do it by hand (you might want to check out Colin Eberhardt’s experience from 2011)… but there are tools out there to help you. There is at least one XAML to HTML conversion tool worth considering (complete with a step-by-step tutorial). And there are consulting companies ready to help.
If you do decide to move your XAML to HTML, you could migrate your application to ASP.NET. However, because ASP.NET is a server-side environment, the lack of an interactive event model will force you to significantly restructure your application. My personal opinion is that, if you’re moving to HTML, you’d be better off moving to some client-side environment.
The obvious client-side environment is Blazor which will let you keep at least some of your existing UI code (assuming that your code is in C#). Blazor also throws in an event model as rich as Silverlight’s, something that’s not always true even in some of the XAML environments. I think that Blazor is such a good choice that, even if your code is in Visual Basic, you should consider converting your VB code to C# just to support migrating to Blazor (and, among other vendors, Progress offers a Telerik VB to C# conversion tool). That does, however, mean moving to .NET Core and you may already have determined that isn’t a good choice for you.
Or you could keep your XAML and move to some existing “XAML-friendly” environment.
The obvious choice here is WPF, which will let you recycle much of your XAML into your new application. With WPF, ClickOnce technology will let users install your application through their browser (not quite the same as running the application in your browser but, probably, “close enough”). You’ll be restricted to running on Windows platforms but, ignoring the Linux Moonlight project (and everybody did), so were your Silverlight applications.
WPF XAML is about as “Silverlight XAML compatible” as you’ll get. If you have do have third-party components, moving to WPF may also reduce your conversion effort. Many of the Telerik Silverlight controls, for example, have corresponding WPF versions. With any luck (and with the right third-party components), much of the XAML that you have in your Silverlight application could be copied and pasted to a new WPF application without much (or, even, any) modification.
You could also consider Microsoft’s Xamarin Forms. While Xamarin is primarily touted as a way to produce smartphone apps (and is very good at it), it also generates desktop UWP applications that support ClickOnce distribution.
The problem is that Xamarin Forms uses a different version of XAML than Silverlight. Your Silverlight TextBlocks will, for example, have to become Xamarin Editors, Entrys, or Labels. Most of the events in Silverlight XAML aren’t supported in Xamarin XAML and, when they are, have different names (Silverlight’s Click attribute corresponds to Xamarin’s Pressed). Clever (and limited) use of Visual Studio’s Find and Replace All could handle some of these changes. However, not all Silverlight attributes have Xamarin equivalents: Xamarin Forms’ HorizontalOptions attribute isn’t really the same thing as Silverlight’s HorizontalAlignment, for example.
But you do have another choice… provided you’re willing to step out of your Microsoft-centric comfort zone: The open-source projects Avalonia and the Uno Platform.
While not Microsoft products, both Avalonia and the Uno Platform deliver cross platform applications using XAML and C#. Both projects use versions of XAML that will minimize your XAML conversion effort (though not, you’ll notice, “eliminate your XAML conversion effort”). The Uno Platform currently delivers applications to Windows, Linux, Mac, Android, iOS, and web browsers (if you’re interested, I’ve written about the experience of creating “your first Uno app”). Avalonia supports a subset of those platforms (smartphone support is still in development and there’s no web browser support). Personally, I think you’d be foolish not to (at least) consider either Avalonia or the Uno Platform.
You may have noticed that I’ve repeatedly used “personal opinion,” “probably,” or “at least” in this post. As that suggests, I doubt that this is an exhaustive list of your options. In fact, if you have more options, I’d appreciate any additions you want to make in the comments. Asking for a friend.
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter also writes courses and teaches for Learning Tree International.
Subscribe to be the first to get our expert-written articles and tutorials for developers!