Mobilize.Net has developed a new tool called Mobilize.Net Silverlight bridge that automates a lot of the conversion process from Windows Phone 8.x code to Universal Windows Platform (UWP).

Prior to UWP, about half of all Windows Phone apps were written using WPS (Windows Phone Silverlight). These apps will need significant changes in order to be compatible with the UWP platform. However, once migrated to UWP, those apps can run on all Windows 10 devices.

The new bridging tool is an extension to Visual Studio, taking as input existing projects for both application code and class libraries and outputs a new UWP project, converting C# and XAML files to the new UWP platform. The tool is a free Visual Studio extension and a technical preview is currently available for download.

To use the tool, download it and run the MSI installer then Mobilize SL bridge becomes available as a Visual Studio extension. Open Visual Studio and load a WPS application, then right click the project from the "Solution Explorer" and select the "Convert to UWP" option. Select the output directory and click "Start" in order to convert the application. After the app is converted, you can either open the new solution in a new Visual Studio instance or go to the folder where the new application was generated.

So what goes into converting an application? The Mobilize SL bridge addresses many of the challenges to rewriting a Windows Phone Silverlight application to run on UWP challenges including:

Project and manifest conversion

Manifests of WPS 8.0 and 8.1 are very different from each other. The big difference is that WPS 8.0 manifests reference elements that come from different namespaces. Mobilize SL bridge saves developers a lot of work by converting both WPS manifest versions to the new UWP one.

The UWP project file is also different from WPS and references different basic assemblies and NuGet packages. Mobilize SL bridge generates the UWP project file and the new JSON project file that manages the NuGet package references. It also converts the WPS assembly and NuGet references to the new ones required by UWP projects.

API changes

UWP is an all new platform that introduces many new API elements when compared to WPS applications. Some of them are similar but others are substantially different. Changes are found through all the APIs via small details like a change in an enumeration or the datatype of a method parameter.

Mobilize SL bridge deals with API changes by providing a mechanism that "maps" elements of WPS APIs to UWP APIs. This feature is known as the Mapping Mechanism and it consists of XAML syntax files that describe the transformation of elements between both platforms. The mappings reduce the amount of manual effort needed to convert the app from the old platform to the new one.

The first release of Mobilize SL bridge includes 700 mappings, based on analysis that Microsoft did for Mobilize.Net of the most frequently used properties, methods, and events (PMEs). An additional 500 hundred mappings will be added in a couple of months and even more will be added in the future. The initial 1200 available by year end should cover about 80% of all APIs used in the Silverlight Phone apps in the Windows Store.

The power of mappings is unlimited as the mechanism to create mappings and publish them is open source. Any Windows Phone developer can create their own mappings and share them through a GitHub repository that Mobilize.Net has created.

XAML changes

XAML files describing both WPS pages and user controls require some changes for UWP. Most UWP controls are similar to WPS ones but some properties and events have changed. In addition to the small changes, new components have been added and some WPS ones have an exact match in the new platform.

Mobilize SL bridge provides the same Mapping Mechanism in order to convert XAML objects from WPS to UWP. Just like PME mappings, transformations between XAML elements are described in a XAML syntax file, and can be created and shared through the GitHub repository.

Async and Await APIs

Starting with Windows Phone 8 many APIs are exposed using Async and Await. These features improve the responsiveness of the application by avoiding blocking threads while waiting for operations to finish.

As indicated earlier here, UWP provides a new API that takes advantage of the Async/Await programming model. This introduces an additional challenge when moving applications from WPS to UWP platform.

Manually changing method calls from a method that is not async to an async version can be tedious, because once a call is changed to async it is necessary to propagate the async keyword through the stack of method calls on top of the method containing the new async call. In addition, calls must be prefixed with the await keyword. The new bridge tool takes care of this problem by allowing code changes with the introduction of just one new async call.

Mobilize SL bridge automates the process by analyzing the code that is involved in the async call, propagating the async and await keywords through the appropriate code path. This propagation is heavily integrated with the Mapping Mechanism, so Windows Phone developers can also indicate which new API methods are now asynchronous.

Extensibility

There’s a large number of Windows Phone Silverlight specific APIs either included with the framework or provided by third party vendors. The APIs that ship with Mobilize SL bridge handle the most common scenarios based on counting which APIs are used most in Windows Phone apps.

If an application uses a specific API extensively that is not included in the tool, work can be saved manually by taking advantage of the Mobilize SL bridge Extensibility Mechanism. To facilitate the process, Mobilize.Net has provided the following:

- All mappings bundled with the tool have been open sourced and published in a public GitHub repository.

- Usage and reference documentation is provided in the same GitHub repository inside the Wiki section.

- In order to use custom mappings in the tool, a developer only needs to copy their own XAML mapping files and Mobilize SL Bridge will automatically load them the next time it runs.

- Because of the nature of GitHub collaboration, developers can either share their own mappings or reuse mappings created by other developers, or even improve core tool mappings by using the GitHub Pull Request