April 30th, 2014

Get your libraries ready for Windows Phone 8.1

Immo Landwerth
Program Manager

Two weeks ago, we released the Windows Phone preview for developers. In this post, I’ll cover what this means for library and app developers.

What this means for library developers

As a .NET developer you can target Windows Phone 8.1 via two platforms:

  • Windows Phone 8.1. This is the new platform which is more converged with Windows and enables developers to share more code between Windows and Windows Phone apps.

  • Windows Phone Silverlight 8.1. This is an update to the existing Windows Phone platform; it allows developers to move their existing apps forward while taking advantage of new Windows Runtime APIs.

Apps that target Windows Phone Silverlight 8.1 can consume existing libraries and NuGet packages as-is – after all, it’s still Windows Phone Silverlight – just an updated version.

Apps that target the new Windows Phone 8.1 platform can only consume libraries and NuGet packages that are built for Windows Phone 8.1. But don’t worry – it’s easy to update your libraries to include support for Windows Phone 8.1.

If you’re already using a portable class library to target Windows Phone, then it’s even super trivial:

  1. First, make sure you have Visual Studio 2013 Update 2 RC installed. You can get the release candidate from here.
  2. Right click your portable class library in Solution Explorer and select Properties. On the Library tab click on Change. This opens a dialog in which you can now add support for Windows Phone 8.1:

Note: If you have the Xamarin Tools installed you might get an error message telling you the selection doesn’t share any portable APIs. That’s a known issue with the current version of the Xamarin tools. Xamarin is working on providing an updated version. For now, the only workaround is to uncheck the Xamarin platforms.

For Windows Phone Silverlight 8 libraries, we recommend creating a new portable class library that targets Windows Phone 8.1 and Windows Phone Silverlight 8.1.

In case you’re redistributing your library via NuGet, you also need to indicate support for Windows Phone 8.1 by using the new lib folder name, which is wpa81. For example:

<package >
  <metadata>
    <id>MyLibrary</id>
    <!-- ... -->
  </metadata>
  <files>
    <!-- Support for portable -->
    <file src="MyLibrary.dll" target="libportable-net45+win8+wp8+wpa81" />

    <!-- Windows Phone 8.1 specific library -->
    <file src="MyLibrary.Phone.dll" target="libwpa81" />
  </files>
</package>

We’ve already updated our NuGet packages to add support for Windows Phone 8.1. This includes the following NuGet packages:

What this means for app developers

Windows 8.1 and Windows Phone 8.1 support a common set of APIs, with few exceptions. This allows you to very easily build your application such that it works on both Windows Phone as well as Windows. With Visual Studio 2013 Update 2, we’ve added a new feature called Universal Apps that makes this process a breeze. You find out more in the post Using Visual Studio to build Universal XAML Apps.

Many of the popular NuGet packages have already added support for Windows Phone 8.1, such as JSON.NET as well as our NuGet packages.

But it’s certainly possible that you’ll want to consume NuGet packages that aren’t enabled for Windows Phone 8.1 yet. In that case, you’ll see an error message like this:

If you hit such a case you should let the author of the package know by using the Contact Owners link on their NuGet page:

Summary

With the Windows Phone 8.1 tooling and OS preview have both been just released, we need the community’s help to update your NuGet packages. If you maintain a library that supports phone, you should update your project and NuGet package so that developers building universal Windows apps can leverage your work.

Enjoy!

Author

Immo Landwerth
Program Manager

Immo Landwerth is a program manager on the .NET Framework team at Microsoft. He specializes in API design, the base class libraries (BCL), and .NET Standard. He works on base class libraries which represents the core types of the .NET platform, such as string and int but also includes collections and IO. He's involved with portable class libraries and works on shipping more framework components in an out-of-band fashion via NuGet.

0 comments

Discussion are closed.