September 17, 2015 10:01 am

Initial preview of Silverlight bridge to UWP

By / Senior Technical Product Manager, Windows Developer Team

Today marks the initial release of Mobilize.NET’s Silverlight bridge, which helps Windows Phone Silverlight app developers bring their WP Silverlight 8.x apps to the Windows 10 Universal Windows Platform (UWP). Announced at Build 2015, the Moblize.NET bridge is free and directly integrates into Visual Studio. The bridge currently maps the 700 most used APIs and handles transitioning your manifests, APIs, XAML, NuGet package references and async/await changes. More APIs and mappings will follow with future updates. Mobilize.NET has a much more in-depth post on the Silverlight bridge that goes into detail on the features, so here we share only a high-level overview of the tool.

Once you use the tool to bring your app to the UWP, your app will have all the power of a UWP app, including the ability to – from a single code base – run on a PC, phone, Xbox, HoloLens, or even a Raspberry Pi.

Running the bridge

Once installed, open up Visual Studio, load your WP Silverlight app, then right-click your project from the Solution Explorer and select the “Convert to UWP” option. Additionally, any project that is in the solution will be migrated.

1_migrateSlToUwp

Helping extend and improve the mappings

The Silverlight bridge does the migration with a feature named the Mapping Mechanism. All mappings bundled with the tool have been open sourced and published in a public GitHub repository (https://github.com/MobilizeNet/UWPConversionMappings). This way developers around the world can use them as a reference implementation to write their own.

Start Migrating

The Silverlight bridge may not do a full transition as this is an initial preview now but the tool should get you most of the way. Since Silverlight is similar to UWP but not the same so most errors should be pretty straightforward to resolve. Once you fix compiler errors, you should be ready to start testing and adjusting your app.

The Building apps for Windows 10×10 article series has some helpful guidance on building apps. Topics range from building responsive UIs, speech, live tiles, to how to help get your app promoted in the Store.

Updated June 28, 2018 9:32 am

Join the conversation

  1. I tried it now on 5 apps. The wizard compeletly failed on 3 of them, the remaining it, it generated a really strange code that cannot be compiled even after manually resolving Nuget depedencies.

    • The sub article does say it’s a technical preview and there are 500 more mappings to help conversion coming. Use of mappings implies if your code is not covered, it won’t work. However it sounds like you can extend it and create/submit mappings to help cover the gaps.

      As with many projects these days, getting involved is one way to help yourself and others out.

  2. I wish to see web as part of UWP, and by that I mean to see a tool that compiles C#+XAML to HTML5+CSS3+JavaScript. That will make UWP deployable as a website, and as a native Android and iOS app (via Apache Cordova)!

  3. I wish UWP apps worked on earlier Windows versions. It’s really frustrating that each time a new Windows appears, the API changes so dramatically. I know that with Windows 10 this was sort of resolved, but it really would be great to write apps that work both on Windows 10 and Windows 8.1 – especially in case of smartphone apps, as there aren’t that many people using Windows Phone / Windows 10 Mobile.

  4. The big questions for me are:
    Is this thing compatible with .NET?
    Is it technically superior to .NET?
    From what I hear it may be a part of the great dumbing down and the answer to the above is NO. While it’s still some gleam in a marketers eye (see comments here about incomplete) I won’t expend my own time finding the answers.

    • Hi Mike, With the Universal Windows Platform, you can 100% write .NET. Just like you could with Windows Phone 7, 8.x, Windows 8, 8.1, and now Windows 10.

      There is a great series about developing on UWP in c# i suggest looking at that will answer a lot of your questions I bet. Watching the Build conference sessions is another great place for in-depth information too. https://channel9.msdn.com/Events/Windows/Developers-Guide-to-Windows-10-RTM
      https://channel9.msdn.com/Events/Build/2015

      • There is an issue of perspective here. Over the years I’ve found myself enthusiastic about technologies. Fortunately I’ve been able to avoid some of the time waste but I’ve seen others fall into the traps. If you think of Visual J++, WebClasses, the Google search API beta, designing on the Win 8 “OS GUI”, trusting that the cloud is secure, the Visual Studio API beta, hailstorm… you’re looking at thousands of man years consumed pointlessly by enthusiastic development.

        I’ve taken a deeper look by trying UWP out in a trivial test case, some of the issues become quite clear.
        There are several definitions of what .NET is and they numbers are growing.
        We used to have “client profile” vs. “real .NET”. I know people for whom only the latter really qualifies. (I’ve been surprised by projects, more than once, set to “client profile” that I had to change to full .NET so that I could do meaningful work.)
        Now we have a “UWP core” version of .NET to add to the mix (and probably de facto versions for various devices).

        I not, here, including mention of the COM / C++ interfaces (although they do illustrate that we’re talking about something that is not pure .NET).

        Convincing others to try something is not without costs.

        For some UWP core is enough, for others only full .NET 4.6 is .NET.

        I’ll test this out further. One issue is whether the “runtime #IFDEF” facilities are worth using or it’s simply better to have a dumber program and a full program that runs desktop/service.

  5. I got this from somebody who writes non trivial code and has tried UWP:
    “I’d say the biggest problem of Windows 10 is its UWP Platform. It’s highly unstable, incompatible with existing Win32/.NET apps, unpredictable, and unreliable. It’s design language is inconsistent and doesn’t differentiate enough from Google Material Design language.”

    That backup up my thinking.

    • “It’s design language is inconsistent and doesn’t differentiate enough from [a later design language]”? I appreciate that your two posts may just be trying to provoke a discussion, but they seem off topic here.

  6. Is there any documentation on the planned coverage – for example, can we check if things like Microsoft.Phone.Data.Linq will be covered, or is this intended to only map those that can be changed simply?

  7. Igor I’m sorry you’re having problems. Please note this is a technical preview, not the final product. We’d really like to understand the issues you encountered; can we arrange under NDA to review the code that you attempted to migrate? You can reach me a john.browne at mobilize.net or call us at +1 425.609.8458.

    John Browne, Product Manager

  8. Would be nice to have a visual tool to define mappings
    Would be nice if it also worked on classic Silverlight web and desktop (OOB) apps