Portable Class Libraries with WP7 support in Visual Studio 2013 (RC)

Note: This is my personal blog. Although I did an internship at Microsoft and this post is about a product made by Microsoft, I figured out the info in this blog post after the internship in my own time without any help. The "hack" described in this blog post, leaves Visual Studio 2013 RC in an unsupported state. Perform it at your own risk.

Update 10/17/2013: It looks like this trick still works for the final release of Visual Studio 2013. Use it at your own risk.

With the recent release of Visual Studio 2013 RC and the Windows 8.1 RTM for MSDN subscribers, I started upgrading some of my code to work with Windows 8.1. Part of this code resided in a Portable Class Library (PCL) that also targets Windows Phone 7.5 (and therefore Silverlight 4) next to Windows Phone 8, Windows 8 and .NET 4.5. Visual Studio 2013 has dropped support for some older platforms including Windows Phone 7.5, Silverlight 4 and older.

Since you can install Visual Studio 2012 and 2013 side by side, you can still continue building Windows Phone 7 apps in 2012 if needed. Problems occur as soon as you want to use a PCL for Windows 8.1 development that also targets Windows Phone 7. Several others also came accross this issue. When opening such a PCL in Visual Studio 2013, it will upgrade the project to Windows Phone 8, Windows 8 and .NET 4.5 as in the picture below and breaks the compatibility with Windows Phone 7 in Visual Studio 2012.

Visual Studio 2013 will upgrade the project.

While I was investigating if I could work around this issue, I found that all the portable profiles are actually there on disk in the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable folder, when you install Visual Studio 2013, including those with support for Windows Phone 7 and Silverlight 4. As Daniel Plaisted pointed out on Twitter, this is because different versions of Visual Studio share the portable profiles.

Folder containing the portable profiles.

I was wondering why Visual Studio would upgrade the project while the profile was there on disk. While digging through the xml files for Profile104 (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETPortable\v4.0\Profile\Profile104\), which is the profile I was using, I found some xml files in the SupportedFrameworks subfolder. These xml files defined a MinimumVisualStudioVersion and a MaximumVisualStudioVersion. For Profile104, one of the files contained MaximumVisualStudioVersion="11" which means Visual Studio 2012. Changing all xml files for the profile to have MaximumVisualStudioVersion="12", which means Visual Studio 2013, made my scenario work after a restart of Visual Studio. I can now open the PCL in Visual Studio 2013 without it being upgraded. Make sure you restart VS after this change to make it work.

Xml file that defines the minimum and maximum Visual Studio versions

Note that changing these xml files is unsupported and leaves you in an unsupported state. It might decrease the stability of Visual Studio 2013 RC, although I did not find any issues with this yet, but that does not mean there are none. Make these changes at your own risk and only for the profiles you really need!

Hope this helps for everyone who still needs to do Windows Phone 7.5 development. If you want support for Windows Phone 7 in Visual Studio 2013, please let the team know via their uservoice site.

Did you like this? Share it:

Introducing Windows.UI.Interactivity: Behaviors for the Windows Runtime

Update: a NuGet package is now available here.

In the Windows Runtime and Blend for Visual Studio 2012 there are no behaviors. This brings lots of problems when you are using the MVVM pattern or you come from the Windows Phone or Silverlight platform. Windows.UI.Interactivity tries to fill this gap by porting the whole System.Windows.Interactivity assembly, where the behaviors live in the Blend SDK, to the Windows Runtime. The project builts on work done by Windows Phone MVP Joost van Schaik a.k.a. LocalJoost and Silverlight MVP Andrea Boschin.

What is a behavior?

A behavior can be seen as an extension method for XAML. Behaviors leverage the power of attached properties and by using them you can extend the functionality of a control without modifying that controls' code.

Why would I care?

When using the MVVM pattern, you want to separate the view from the model. You bind the view to the viewmodel using the powerful data binding properties and the viewmodel should handle the interactions between the view and the model. Unfortunately you can not bind events easily to the viewmodel. This is where behaviors come in. Behaviors can be bound to the viewmodel and they also have access to the object they were attached to. In this way a behavior can register for an event and update a property on the viewmodel or fire a command, whenever an event fires. This is basically what EventToCommand from Laurent Bugnion does. By using Windows.UI.Interactivity you can again use behaviors as before and it also makes porting Windows Phone apps easier.

Great! How do I use it?

Using the library is very simple. Just use it as if it was System.Windows.Interactivity from the Blend SDK. Of course you need to update the namespace to the new Windows Runtime format (xmlns:i="using:Windows.UI.Interactivity"), but that is all you need to do! Any existing behaviors also need to be recompiled to work with this library. To get you started, a sample application is included with a basic ClickBehavior to show how it all works. Just download the code from github and add a reference to it to your app or install the library via NuGet.

Did you like this? Share it: