Porting Windows Phone Silverlight to XAML Windows Runtime 8

Article
10/14/2015

[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]

Note For info about porting to a Universal Windows Platform (UWP) app for Windows 10, see Move from Windows Phone Silverlight to UWP.

When porting a Windows Phone Silverlight app to the model for XAML Windows Runtime apps, most of your knowledge and experience will transfer, as will much of your source code and the software patterns you use. Even your UI markup and design can port over readily. You may be surprised at how relatively easy the process is, even if there is a challenge or two along the way.

As you read this porting guide, you can refer to the topic before this one: Windows Phone Silverlight to Windows Runtime namespace and class mappings. Fairly straightforward mapping is the general rule, but there are a few exceptions. The namespace and class mappings table describes any exceptions, but also see the few exceptions at the feature level listed in this topic's parent.

Additional info about Windows Store apps with XAML in general can be found at Roadmap for Windows Runtime apps using C# or Visual Basic.

Approaching porting layer-by-layer

View. The view (together with the view model) makes up your app's UI. Ideally, the view consists of markup bound to observable properties of a view model. Another pattern (common and convenient, but only in the short term) is for imperative code in a code-behind file to directly manipulate UI elements. In either case, much of your UI markup and design—and even imperative code that manipulates UI elements—will be straightforward to port.
View models and data models. Even if you don't formally embrace separation-of-concerns patterns (such as MVVM), there is inevitably code present in your app that performs the function of view model and data model. View model code makes use of types in the UI framework namespaces. Both view model and data model code also use non-visual operating system and .NET Framework APIs (including APIs for data-access). And the vast majority of those are available to a Windows Runtime app, so you can expect to be able to port much of this code without change. Remember, though: a view model is a model, or abstraction, of a view. A view model provides the state and behavior of UI, while the view itself provides the visuals. For this reason, any UI you adapt to the different form factors that the Windows Runtime allows you to run on will likely need corresponding view model changes.
Cloud services. It's likely that some of your app (perhaps a great deal of it) runs in the cloud in the form of services. The part of the app running on the client device connects to those. This is the part of a distributed app most likely to remain unchanged when porting the client part. If you don't already have one, a good cloud services option for your Universal Windows app is Microsoft Azure Mobile Services, which provides powerful back-end components that Universal Windows apps can call for services ranging from simple notifications for live tiles updates up to the kind of heavy-lifting scalability a server farm can provide.

Before or during the porting, consider whether your app could be improved by refactoring it so that code with a similar purpose is gathered together in layers and not scattered arbitrarily. Factoring your Universal Windows app into layers like those described above makes it easier for you to make your app correct, to test it, and then subsequently to read and maintain it. You can make functionality more reusable—and avoid some issues of UI API differences between platforms—by following the Model-View-ViewModel (MVVM) pattern. This pattern keeps the data, business, and UI parts of your app separate from one another. Even within the UI it can keep state and behavior separate, and separately testable, from the visuals. With MVVM, you can write your data and business logic once and use it on all platforms. It's also very likely that much of the view model and view parts can be reused across platforms, too, although that varies between apps.

The app package manifest

It's worth knowing how to edit the app package manifest, because the topics that follow talk about using it for various declarations, capabilities, and other settings that some features need. You can use the Visual Studio app package manifest editor to edit it. If the Solution Explorer is not shown, choose it from the View menu. Double-click Package.appxmanifest. This opens the manifest editor window. Select the appropriate tab to make changes and then save.

In this section

Topic	Description
Porting the project	You begin the porting process by creating a new Windows Runtime project (a type of Store project) in Visual Studio and copying your files into it. If you choose to create a Universal App project then you'll be able to support PCs, tablets, and phones from one code base.
Troubleshooting	We highly recommend reading to the end of this porting guide, but we also understand that you're eager to forge ahead and get to the stage where your project builds and runs. To that end, you can make temporary progress by commenting or stubbing out any non-essential code, and then returning to pay off that debt later. The table of troubleshooting symptoms and remedies in this topic may be helpful to you at this stage, although it's not a substitute for reading the next few topics. You can always refer back to the table as you progress through the later topics.
Porting XAML and UI	The practice of defining UI in the form of declarative XAML markup translates extremely well from Windows Phone Silverlight to Windows Runtime apps. You'll find that large sections of your markup are compatible once you've updated system Resource key references, changed some element type names, and changed "clr-namespace" to "using".
Porting for I/O, device, and app model	Code that integrates with the device itself and its sensors involves input from, and output to, the user. It can also involve processing data. But this code is not generally thought of as either the UI layer or the data layer. This code includes integration with the vibration controller, accelerometer, gyroscope, microphone and speaker (which intersect with speech recognition and synthesis), (geo)location, and input modalities such as touch, mouse, keyboard, and pen.
Porting business and data layers	Behind your UI are your business and data layers. The code in these layers calls operating system and .NET Framework APIs (for example, background processing, location, the camera, the file system, network, and other data access). The vast majority of those are available to a Windows Runtime app, so you can expect to be able to port much of this code without change.
Porting for form factor and UX	Windows apps share a common look-and-feel across PCs, tablets, and phones. The user interface, input, and interaction patterns are very similar, and a user moving between devices will welcome the familiar experience. But practical differences between devices such as physical size, default orientation, and effective pixel resolution factor into the design of a Universal Windows app.
Case study: Bookstore1	This topic presents a case study of porting a very simple Windows Phone Silverlight app to a Universal Windows app (using the Windows Runtime, or WinRT). The app consists of a ListBox bound to a view model. The view model has a list of books that shows title, author, and book cover.
Case study: Bookstore2	This case study, which builds on the info given in Bookstore1, begins with a Windows Phone Silverlight app that displays grouped data in a LongListSelector. In the view model, each instance of the class Author represents the group of the books written by that author, and in the LongListSelector we can either view the list of books grouped by author or we can zoom out to see a jump list of authors.
Case study: Bookstore3	This case study is the third in a series showing how to port Windows Phone Silverlight apps to Universal Windows apps (using the Windows Runtime, or WinRT). It is intended to complement the porting techniques we learned in Bookstore1 and Bookstore2, and the app we'll look at here adds important new features to its view model and to its user interface.