Telerik blogs
DotNetT2 Light_1200x303

Good news: If you’ve waited until now to convert your Silverlight applications to some other Microsoft technology, you picked the right time to convert: WPF in .NET Core is ready to give your apps a longer future.

Although conversion can be relatively painless, here’s some advice to simplify the process.

So, you’re about to recreate your Silverlight applications in another technology with a longer lifetime. The current version of .NET Core not only supports WPF (finally) but makes converting relatively painless. If you take advantage of some Visual Studio features, you can further simplify the process.

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:

Supporting Silverlight in Visual Studio 2017/2019

Visual Studio 2019 supports WPF in .NET Core… but won’t open Silverlight projects. You could open your existing Silverlight project in, say, Visual Studio 2015 and create your new WPF project in Visual Studio 2019. Switching between two copies of Visual Studio isn’t awful but it’s isn’t fun, either. Your conversion task will be considerably simpler if you open both projects in the same copy of Visual Studio.

That’s actually possible in both Visual Studio 2017 or 2019 thanks to Rami Abughazaleh’s Silverlight for Visual Studio. You can install this Silverlight extension from Visual Studio’s Extensions > Manage Extensions menu choice. Once the extension is installed (which will require you to shut down and restart Visual Studio), you need to make one more change before you’ll be able to open a Silverlight project: In Visual Studio, go to the Tools > Options menu, click on the Environment node, find the Extensions tab, and check the “Allow synchronous autoload of extensions” option. You should now be able to open existing Silverlight projects in Visual Studio. You won’t get a visual designer for your Silverlight XAML files but, on the other hand, since you’re leaving Silverlight behind, you don’t really need it.

Before you start dragging files from your old Silverlight project to your new WPF project, make your WPF project your start project and press F5. You’ll almost certainly get an error message that your Silverlight web project can’t access the Silverlight project’s DLL (Windows is suspicious of executable code that appears to be downloaded from the web like, for example, your Silverlight DLL). You don’t really need the web project to do the conversion, so the easiest solution to this problem is just to remove the Silverlight web project from your new solution by clicking on the project in Solution Explorer and pressing the Delete key.

You’re ready to start your conversion. Once you’ve got your Silverlight project open, use File > New > Project to add a new WPF project to your solution (use the WPF app (.NET Core) template). Much of your Silverlight conversion can now be handled just by dragging files and folders from your Silverlight project to your WPF project and adding references for the class libraries that your Silverlight project uses to your new WPF project. You’ll find, for example, that the XAML visual designer in your new WPF project works just fine.

Supporting WCF in Visual Studio 2017/2019

It is, however, possible (even likely) that your Silverlight application is sufficiently old that it’s using WCF to access Web Services. Assuming you’re not going to rewrite those Web Services in a RESTful kind of way, you’ll want to add service references for those libraries to your WPF project. The good news is that you can do that in both Visual Studio 2017 and 2019, though the process is slightly different in the two versions.

To start connecting to your WCF service, right-click on your WPF project and, from the popup menu, select Add > Connected Service to open the connect services editor. Under the Other Services header, you should find the Microsoft WCF Web Service Reference Provider (Visual Studio 2017 may not have the Other Services header but should have the Reference Provider). Clicking on the Reference Provider opens a familiar looking dialog that should let you connect to your existing WSDL/SOAP Web Service.

Converting XAML

Now you can start dragging files and folders from your Silverlight project to your WPF project. What you don’t want to do is make any changes to your baseline Silverlight app which, I assume, has that “working” feature that users like so much (one of the nice features of Visual Studio’s support for drag-and-drop between projects is that the files are copied rather than moved, leaving your Silverlight project intact).

I’d recommend (at least, initially) dragging .xaml/.xaml.cs file combinations over one at a time and using Visual Studio’s Find-and-Replace functionality to convert the namespaces in the old Silverlight files to the namespace in your new WPF project. Just make sure that you set scope of your changes to Current Project (your WPF project), rather than Entire Solution (again, the goal is to leave the original Silverlight project unchanged).

You can now decide how much work you want to invest in converting your Silverlight UserControls. You can, for example, just point your App.xaml file at the Silverlight UserControl that is your app’s start point (in App.xaml, just set the StartupUri attribute on the Application element to the file name of your initial Silverlight UserControl). That does result in a slightly odd-looking title bar that includes forward and backward buttons for your application’s window but reduces the changes required to your Silverlight’s navigation system.

Alternatively, you can add your Silverlight UserControls to WPF Windows to get a more native-looking UI. Adding a UserControl can be as simple as the following example, which adds a Silverlight UserControl (called MySilverlightUserControl) to a WPF window (called MyWpfWindow) in a project with the namespace MyWpfApplication:

<Window x:Class="MyWpfApplication.MyWpfWindow"
        Title="MainWindow" Height="450" Width="800">

          <local:MySilverlightUserControl></local: MySilverlightUserControl>

While that gives you a more “native” looking WPF interface, it also gives you twice as many files as you need since each Silverlight/UserControl XAML file is going to have a matching WPF/Window XAML file). You have one other option: You can convert your Silverlight UserControls into “native” WPF Windows by changing the UserControl element’s name to Window. The default attributes between WPF Windows and Silverlight UserControls are almost identical (and the differences don’t seem to matter).

You’ll have a great deal more to do, of course (you’ll probably want to overhaul your navigation system, for example). But you’re now working in about as friendly environment for the conversion as you can get.

Peter Vogel
About the Author

Peter Vogel

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.

Related Posts


Comments are disabled in preview mode.