Leaving Silverlight: Converting to the Web

If you’re migrating from Silverlight, the latest crop of technologies means that going to the web might be your best choice.

You’ve decided to recreate your Silverlight applications in some technology with a future that doesn’t end in October 2021. You could move to WPF, but taking your application to the web is not only the smarter choice, it might be less work than you think.

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:

• Leaving Silverlight: Your Options
• Leaving Silverlight: Converting to WPF .NET Core

If you’re moving away from Silverlight, your two best options are either to recreate your Silverlight functionality in WPF or the web environment. Certainly, WPF is the obvious choice, but it’s never been a zero-cost solution. More critically, WPF limits you to the Windows platform at the very moment when .NET Core expands your horizons to Mac, iOS, Android, and Linux. Moving to the web is not only a cross-platform solution, client-side browser–based applications are also a pretty good fit to Silverlight: The HTML/document object model event model is the equal to Silverlight’s and, with CSS, you have something approaching Silverlight’s Style objects.

You might dismiss moving your Silverlight application to the web because of the effort involved in converting your XAML to HTML and your C# to JavaScript. The good news here is that there is some help/advice/tooling that you can take advantage of to reduce the pain and suffering in converting your XAML and, if you pick the right technology set (<cough>Blazor</cough>), you don’t have to convert your C# code.

In fact, if you’re willing to look at the bleeding edge of technology (and I’m not making any promises here), you might not have to convert your XAML to HTML, either.

XAML to HTML

If, however, you’d like to stick with the Microsoft toolkit, converting your XAML to HTML is unavoidable (right now, at any rate). And, yes, it is possible to convert your XAML to HTML by yourself. It’s also possible, if you’re trapped at the South Pole, to remove your own appendix. However, neither task is going to be either easy or fun.

Take, for example, the Silverlight DataGrid: There is a ton of functionality in that component. You could, I guess, build an equivalent piece of functionality yourself using HTML, JavaScript, and CSS. And that would be an excellent strategy, if you’re paid by the hour. In fact, because of the enormous amount of functionality built into even the simplest Silverlight component (think of all the things that the TextBlock does, for example), I don’t think converting XAML to “pure” HTML is really an option.

The one piece of advice that I’d give you in this area is to migrate to third-party HTML controls that duplicate the functionality of the XAML components you’re using. If you’ve used controls from some third party in your Silverlight applications, that company is where you should look first for web-based components, but there’s nothing stopping you from mixing HTML components from several sources.

As an example, Progress offers packages of Telerik components for several web environments and all those packages include several textbox replacements—you can pick the one that comes closest to how you’re using the TextBlock in any particular Silverlight window. If you used Telerik controls in your Silverlight application, I’d look at the Telerik control packages first, for example.

The Blazor Option

Of course, going to the web also implies that you’ll have to convert your C# code to JavaScript… unless you recreate your app in Blazor. Blazor will not only allow you to keep your C# code, it will also allow your users to install your Silverlight application as a desktop app.

If you’ve used the MVVM model, then the less code you have in your xaml.cs files, the easier a conversion to Blazor will be (and there are pioneers you can follow). If you have model classes that implement the INotifyPropertyChanged interface, you can catch the events they raise in your Blazor component as easily as you can in Silverlight, as I’ve discussed elsewhere. You can also recycle any classes you have that implement the ICommand interface in Blazor, though not as cleanly as you did in Silverlight.

Blazor also duplicates some of Silverlight’s databinding support for the MVVM pattern through the DataContext and EditForm object. The Blazor DataContext object even fires a FieldChanged event which you can use like the DataContext’s Changed event. As an example, Blazor code like this creates a form tied to a model (Customer) and a method tied to the form’s OnFieldChanged event:

<EditForm Model="@typeof(Customer)" 
          OnValidSubmit=HandleValidSubmit>
   <DataAnnotationsValidator />
   <ValidationSummary />

   First Name: <InputText @bind-Value="cust.FirstName" />
    <ValidationMessage For="@(() => cust.FirstName)" /><br />
   <button type="submit">Submit</button>
</EditForm>

private EditContext econtext;
       private Customer cust { get; set; }

       protected override async Task OnInitializedAsync()
       {
          econtext = new EditContext(cust);
          econtext.OnFieldChanged += ManageEdits;

And I shouldn’t suggest that applications that didn’t use MVVM can’t be migrated to Blazor: Binding properties to fields and methods to events is very easy in Blazor.

The Bleeding-Edge Option: Keep Your XAML

And you might not have to convert your XAML to HTML. CSHTML5 (also called “C#/XAML for HTML5”) has a tool to convert your XAML and C# into HTML and JavaScript while you keep working in your original XAML/C# source code. In March of 2019, the project went open source. The project is averaging over 20 commits a month, up to and including August of this year, with multiple contributors.

I will admit to being skeptical, especially when it comes to converting C# code to JavaScript (despite the existence of the Bridge.NET transpiler which CSHTML5 leverages). I was happy, therefore, when CSHTML5 released a technology preview in the second quarter of 2020 that incorporates WebAssembly, eliminating the need to convert your C# code. Having said all that, I should note that CSHTML5 commits only to compiling “a large subset of Silverlight and WPF code to HTML and JavaScript.”

But given that the Bridge.NET transpiler does exist, there is the possibility that you can convert your existing C# code to JavaScript. Once you’ve done that, you can consider moving to some other JavaScript client frameworks than Blazor. Bridge.NET lets you continue to work in C# while providing support for the current “big 3” frameworks: React, Vue, and Angular. All three of those frameworks support MVVM (Vue was designed with MVVM in mind; as usual with React, there’s an extension for MVVM; Angular’s two-way binding works well with the MVVM pattern). However, Bridge supports many other JavaScript libraries, including one of my favorite MVVM libraries, Knockout.

One last bleeding-edge option and then I’ll stop: Microsoft’s Experimental Mobile Blazor Bindings also offers hope that you can leave Silverlight without leaving XAML. However, in addition to having the word “Experimental” in its name (and, currently, only being at version 0.4), the project templates currently target only the Android and iOS platforms. Still, it’s hard to come up with a reason for restricting a version of XAML that works with Blazor to just smartphones, so the future may be brighter.

Conclusion

There are two important takeaways here. First: WPF is not only not your only choice. Two: It may not even be your best one.