In recent years, a lot of applications were written in Silverlight. It is undoubtable that many developers want to port those applications to Windows Store app. This article provides some guidelines and a sample solution to simplify the migration process.
The sample Silverlight application is a typical news publishing application, built with the Silverlight Navigation Application project template. It contains the following pages:
There’s also an ASP.NET MVC web application that hosts the Silverlight application, and provides a RESTful service that encapsulates the business logic.
On the backend, there’s a SQL Server database which stores the news contents and membership/role data. Entity Framework is used to access the database. Business logic is implemented in C# in the same project (note in real world, it is not uncommon to put business logic to a separate assembly). A service layer is used to expose the business logic to clients, such as the Silverlight application. The service is a RESTful service built with ASP.NET Web API.
ASP.NET membership/role is used to manager users and roles. Authentication is handled in the web site, instead of in the Silverlight application.
While most ASP.NET applications are server centric, many Silverlight applications are client centric. The Silverlight client application renders UI, handles user interaction, and sends HTTP requests to a backend service to perform business logic. Windows Store apps take the same approach. In addition, Silverlight is based on the XAML framework. XAML is also supported in Windows Store apps. So migrating a Silverlight application to Windows Store app is much easier compared to migrating an ASP.NET application. Existing architecture as well as a lot of code can be reused.
But there’re still some differences.
First of all, Silverlight supports both in browser scenarios and out of browser scenarios (OOB), but all Windows Store apps are out of browser. Many Silverlight applications do not implement OOB, so when porting to Windows Store app, developers have to learn not to rely on browser features, such as automatically cookie management.
In addition, many complex Silverlight controls, such as DataGrid, are not supported in Windows Store app. But Windows Store app has its own complex controls.
Finally, Windows 8 has a lot of unique features, such as application bar, contracts, live tiles, etc. It is recommended to take advantage of those features when appropriate.
In general, the migration steps can be summarized as:
Developers need to do some high level changes. For example, most namespaces used in Silverlight and Windows Store are different. Silverlight namespaces typically begin with System, while Windows Store namespaces typically begin with Windows.
XAML namespace references also need to be changed. In Silverlight, namespace references are specified as:
In Windows Store, the correct syntax is:
Assembly references also need to be changed. Most Windows Store assemblies are WinRT components instead of CLR assemblies. They’re built with C++. Developers reference the .winmd metadata files instead of the .dll files. Certain CLR assemblies can also be used in Windows Store app, including some commonly used third party assemblies like Json.NET. But if a CLR assembly relies on a feature not supported by WinRT (such as Workflow Foundation and GDI+), it cannot be used. Fortunately, most of those features are not supported in Silverlight, either. On the other hand, Silverlight assemblies cannot be used in Windows Store apps. Developers have to find desktop equivalents. When using Visual Studio to create a new Windows Store app, the correct assemblies are already referenced.
Silverlight navigation model is a bit different from Windows Store. Silverlight uses URIs while Windows Store uses types.
Consider a typical line of Silverlight navigation code:
this.NavigationService.Navigate(new Uri("/Read", UriKind.Relative));
To migrate it to Windows Store, write:
Because types are used instead of URIs, URI mapper is no longer needed.
Windows Store apps are not in browser apps. So there’s not back/forward buttons. Developers can provide their own back/forward buttons and implement navigation logic if necessary.
When using the Grid Application project template provided by Visual Studio¸a basic navigation framework is implemented in the LayoutAwarePage. It includes a full featured back button. LayoutAwarePage also helps the application to automatically suit different layouts, such as portrait orientation and snapped view. Developers can use the Basic Page item template (not Blank Page) to create new pages inheriting from LayoutAwarePage.
There’re a lot of Silverlight controls, natively supported in Silverlight runtime or provided in additional class libraries such as Silverlight SDK and Toolkit.
Most controls provided natively by Silverlight runtime are also supported by Windows Store apps, and the usage is very similar, if not identical. For example, Button and TextBox can be used as is. Windows Store’s ListBox with custom ItemTemplate is also identical to the same ListBox in Silverlight.
But most controls provided in the Silverlight SDK and Toolkit are not supported in Windows Store apps. In particular, DataGrid is not supported. DataGrid is frequently used in business applications, but it is also used in consumer oriented applications quite often. Windows Store app offers its own set of controls. For example, GridView allows developers to display a list of data using standard Windows 8 styles. It also supports advanced features such as grouping. A read only DataGrid can be easily ported to a ListBox or a GridView. If inline editing is required, developers need to think if this is a valid scenarios for Windows Store apps. Windows Store apps can be used on tablets with no hardware keyboard, so it is recommended to limit user input requirement. Developers can always continue to build Silverlight or other desktop applications if they only need to support PCs.
While certain controls are different, the control models are very similar. Windows Store app’s ContentControl can also render any contents. ItemsControl can use the same data binding model and data template. Control styling and templating models are also identical. So developers do not need to learn a new framework. They just need to learn how to use some new controls.
To get started with Windows Store app’s data presentation controls, please refer to http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh780615.aspx.
Some Silverlight applications rely on browser features. Windows Store apps are not hosted in a browser. So those code must be removed. Typical scenarios include:
Silverlight supports both browser HTTP stack and client HTTP stack. Browser HTTP stack has a lot of limitations. For example, it only supports GET and POST. It doesn’t recognize the proper status code, and so on. But it has a nice feature that is not available in client HTTP stack: It handles cookie automatically. So when authentication is needed, many developers choose to use browser HTTP stack.
Windows Store apps only support client HTTP stack. It supports all HTTP methods and all status code. But it doesn’t handle cookie automatically. As pointed out above, it is recommended to build stateless services whenever possible, so no cookie is needed.
Silverlight supports both SOAP and REST, so does Windows Store apps. When consuming Silverlight compliant SOAP services, developers can add service references, and use WCF client stack to access the service. Most code are identical. Similar to Silverlight, all services must be access asynchronously.
When accessing REST services, developers can continue to use HttpWebRequest. But the simpler WebClient class cannot be used. Windows Stores app provides an HttpClient class, which is much more powerful then WebClient, and much easier to use than HttpWebRequest. When used in combination with the new async/await keywords, developers do not need to worry about callbacks. It can replace HttpWebRequest in most cases. For more information about HttpClient, please refer to http://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh781239.aspx.
To parse the data returned by the service, developers can continue to use existing skills. For example, use LINQ to XML to parse XML data, and use Json.NET to parse JSON data.
If a REST service is compatible with OData, developers can continue to use Visual Studio’s add service reference feature and WCF Data Services client library to access the service.
Some Silverlight applications use WCF RIA Services. WCF RIA Services do not integrate natively with Windows Store apps. But WCF RIA Services can expose limited SOAP/OData endpoints, and thus developers can continue to use certain features.
As pointed out above, Silverlight browser HTTP stack only supports GET and POST, and it doesn’t recognize a proper status code. So an existing Silverlight compatible REST service may take the same approach.
But a well written REST service follows a standard convention. For examples, it commonly uses at least 4 HTTP methods: GET/POST/PUT/DELETE, and it returns a proper status code (such as 400 for bad request). They are all supported in Windows Stores apps. It is recommended to follow REST convention. Do not always use POST, and do not always return 200. So modify the service if needed.
In addition, if the Silverlight application relies on WCF RIA services, developers have to either expose SOAP/OData endpoints from the service, or migrate the service to a standard SOAP/REST/OData service. In the long run, it is recommended to use REST or OData, as they’re supported on almost all platforms.
Windows Store apps provide a lot of unique user experience. Below is a list of common features developers may consider to add in their apps.
Many Silverlight applications use ASP.NET membership to implement authentication and roles to implement authorization. They essentially let the hosting web site handle all authentication and authorization task. This works great if the application only needs to support browser clients. Browser clients can essentially delegate all authentication/authorization to server. A cookie can be used to store a token, which is validated on the server when the request is made.
On the other hand, non-browser applications do not have cookie built-in. To make the sign in process more secure, a client application should not get user’s credential directly. A typical practice is to embed a web browser in the client application. The browser handles authentication, notifies the host app when the user is authenticated, sends the host app a token, and the host app can then use the token to communicate with the service in future requests without asking the user to sign in again.
Windows Store apps (or more precisely, WinRT) offers a system component to simplify the process. Developers can use WebAuthenticationBroker to sign in to any services compatible with OAuth standard. Using WebAuthenticationBroker, developers do not need to worry about how to interact with a web browser control. What’s more, WebAuthenticationBroker simplifies SSO (single sign on). For more information, please refer to http://msdn.microsoft.com/en-us/library/windows/apps/xaml/Hh465283(v=win.10).aspx.
On the server side, the authentication logic also needs to be modified. ASP.NET MVC 4’s new project templates help developers to generate web applications that support common online identity providers (such as Windows Live ID and Facebook) with only a few lines of code. Under the hook, an open source product DotNetOpenAuth is used. Developers can port the MVC project templates to ASP.NET Web API with some additional efforts.
The Silverlight application mentioned earlier has been ported to a Windows Store app. The migrating process follows the above steps.
The resulting app contains following pages. The feature set is almost identical to Silverlight, but the UI is somewhat different.
In addition to the pages, several new features are implemented:
The service layer is modified to follow REST convention. It no longer supports Silverlight workarounds. A few new code is added to provide additional features. HttpClient is used in most places to communicate with the service.
Authentication is handled by Facebook, instead of a local membership database. But Facebook accounts are integrated with ASP.NET membership. WebAuthenticationBroker is used on the client side. On the service side, DotNetOpenAuth is used to handle most authentication logic, while some custom code is provided to make DotNetOpenAuth work with ASP.NET Web API and WebAuthenticationBroker.
To use the app:
On the home page, watch the news list. Use the app bar to sign in.
Sign in using the Facebook account:
If the Facebook account is an administrator, a new app bar command Admin will be displayed. Click it to navigate to the admin/publish pages. Otherwise the user can only add comments to existing news. On the home page, click the header of a group or a news item to go to the detailed pages.
This article and the corresponding demos demonstrate how to migrate a typical Silverlight app to a Windows Store app using XAML + .NET. A news publish system is used as a demo.
The demos are a Silverlight news publishing system and a corresponding Windows 8 application. Features include:
• Basic UI migration: Migrate from Silverlight controls to Windows Store app controls.
• Data presentation UI migration: Migrate from Silverlight DataGrid to Windows 8 GridView/ListBox.
• Service access code migration: Migrate from WebClient/HttpWebRequest to HttpClient.
• Authentication migration: Migrate from ASP.NET forms authentication to OAuth. Integrate with Windows 8 WebAuthenticationBroker. Implement federation with popular online identity providers such as Facebook.
• Search migration: Migrate from custom search UI to Windows 8 search charm.
• Navigation migration: Migrate from Silverlight navigation to Windows Store app navigation. Migrate certain links to application bar.
• Add more Windows 8 specific features: Share, live tile, secondary tiles, etc.