Compartilhar via

Migrate Silverlight applications to Windows Store apps

  • Artigo

Introduction

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

The sample Silverlight application is a typical news publishing application, built with the Silverlight Navigation Application project template. It contains the following pages:

  • ·         Home page: Displays the latest news in each category.
  • ·         News list page: Displays search results, or all news belong to a category.
  • ·         Read page: Displays each new in detail. It also allows users to add comments if they’ve signed in.
  • ·         Admin page: A backend page that is used to manage contents.
  • ·         Publish page: A backend page that allows administrators to publish news.

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.

Migration Consideration

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.

Developers can use both HTML and XAML frameworks to build Windows Store apps, and when using XAML, developers can use both .NET and native C++. A typical Silverlight application is built with XAML + .NET, so this article focuses on the XAML + .NET approach, which is the recommended path for most migrating scenarios. If necessary, C++ can be used to build performance critical components (such as complex rendering using DirectX) that are used by a .NET application, or when a native component that does not have a .NET wrapper is needed (such as Media Foundation). C++ applications cannot use .NET assemblies, but it can use many native libraries. If cross platform is a high priority, developers can choose HTML + JavaScript, which is supported on almost all platforms. But in most scenarios, it is best to port Silverlight to Windows Store using XAML + .NET.

Migration Guideline

In general, the migration steps can be summarized as:  

  • ·         Change namespaces and assemblies
  • ·         Migrate navigation model
  • ·         Migrate controls
  • ·         Remove browser dependent code
  • ·         Migrate service accessing code
  • ·         Modify the service if needed
  • ·         Add Windows 8 Unique Features
  • ·         Migrate authentication

Change namespaces and assemblies

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:

xmlns:local="clr-namespace:TheNamespace"

In Windows Store, the correct syntax is:

xmlns:local="using:TheNamespace"

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.

Migrate navigation model

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:

this.Frame.Navigate(typeof(Read));

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.

Migrate controls

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 https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh780615.aspx.

Remove browser dependent code

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:

  • ·         Browser integrated navigation model: See above to learn how to migrate the navigation model.
  • ·         Dependence on cookies, such as session ID: It is recommended to build stateless services whenever possible. Certain stateful services can be migrated to stateless services. For example, most stateful scenarios involve the user to sign in to the web site, and establish a session. Modern applications use tokens rather than sessions to handle authentication. Later in this guide you will learn how to migrate authentication code.
  • ·         Interacting with hosting HTML page: Developers must move to a full HTML approach (choose HTML + JavaScript) or a full XAML approach. Those two frameworks cannot be used at the same time. But non-UI components can be reused. For example, developers can build a custom WinRT component using either .NET or C++, and use it in a JavaScript application.

Migrate service accessing code

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 https://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.

Modify the service if needed

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.

Add Windows 8 Unique Features

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.

  • ·         Application bar: Application bar offers a standard model for users to invoke commands. Users no longer need to find links/buttons all over the UI to find a certain feature. For more information, please refer to https://msdn.microsoft.com/en-us/library/windows/apps/xaml/Hh781230(v=win.10).aspx.
  • ·         Live tiles: Live tiles are tiles pinned on the start screen. Users use live tiles to glance at app contents without running the app. Tiles can be updated at a regular interval using either data in local storage or data from a cloud service. Each app can create more than one tiles. For more information, please refer to https://msdn.microsoft.com/en-us/library/windows/apps/xaml/Hh868259(v=win.10).aspx.
  • ·         Search contract: Search is essential to many applications. A common practice is to provide a search control on the top of every page. In Windows 8, the search contract offers a centralized place to search. Using search contract, users cannot only search contents in the current application, but also contents in other apps, file systems, and so on. For more information, please refer to https://msdn.microsoft.com/en-us/library/windows/apps/xaml/Hh868180(v=win.10).aspx.
  • ·         Share contract: Many apps are not isolated. They can work together. The share contract offers a centralized place to share content between apps. For example, a user may want to share a link from a certain app. Once the share contract is opened, all apps that accepting links sharing will be listed. If the user frequently uses Facebook, it is very likely he/she has installed a Facebook app. Thus the link can be shared with that app, without having to go to the Facebook web site. For more information, please refer to https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh871363.aspx.
  • ·         Settings contract: Settings contract offers user a centralized place to change app settings. They do not have to learn to go to a different place to change settings when using a new app. For more information, please refer to https://msdn.microsoft.com/en-us/library/windows/apps/xaml/hh770543.aspx.
  • ·         Built-in theme animations. Windows Store apps use the same animation framework as Silverlight. On top of that, it provides several theme animations that further simplifies animation development. Animation is a great way to improve user experience. For more information, please refer to https://msdn.microsoft.com/en-us/library/windows/apps/xaml/Hh452701(v=win.10).aspx.

Migrate authentication

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 https://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.

Demo for Migrating Silverlight application to Windows Store App

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.

  • ·         Home page: Displays the latest news in each category, but the search control has been moved to the search contract. A GridView is used to display the data.
  • ·         News list page: Displays search results, or all news belong to a category. A GridView is used to display the data.
  • ·         Read page: Displays each news in detail. It also allows users to add comments if they’ve signed in. The comment list is displayed using a ListBox.
  • ·         Admin page: A page that is used to manage contents. A ListBox is used in place of a DataGrid.
  • ·         Publish page: A page that allows administrators to publish news.

 

In addition to the pages, several new features are implemented:

  • ·         Share the news with other apps using the share contract.
  • ·         Live tile notification to provide the user the latest news without launching the app.
  • ·         Application bar is used to place common commands.

 

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.

Conclusion

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.

 

 

Sample Project.zip

Comments

  • Anonymous
    November 11, 2012
    Lots of applications that were built in SL, were LoB apps that used RIA Services (which becomes a big part of your app) to do all your data plumbing. Now if you try to move to Win8, you have NOTHING in Win8 that resembles RIA Services to move over. You're dead right there! ..Ben

  • Anonymous
    November 12, 2012
    Silverlight apps run on Mac too. That was a selling point for Silverlight.

  • Anonymous
    November 25, 2012
    Excellent article. Thanks for sharing.

  • Anonymous
    May 26, 2013
    The comment has been removed