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:

Fixing the LongListSelector part 2: Making the SelectedItem bindable.

One of the problems of the LongListSelector in the current release of the Silverlight for Windows Phone Toolkit comes to the surface in MVVM scenarios. You often bind the SelectedItem to some property on the viewmodel so you can have access to the selected item. This works fine for a ListBox, but on the LongListSelector it doesn't work.

The problem is that the SelectedItem property on the LongListSelector is not a dependency property, and is therefore not bindable. The solution to this problem is of course to change it to a dependency property. But if you don't want to change the source and recompile there is also another way to add this.

The following piece of code creates a new control which inherits from the normal LongListSelector.

- It adds a new dependency property called SelectedItem and hides the SelectedItem property of the base class by using the "new" modifier.

- It explicitly sets the SelectedItem dependency property when the selection changes, which in fact comes down to syncing the dependency property with the  SelectedItem property of  the base class.

 public class LongListSelector : Microsoft.Phone.Controls.LongListSelector
    public LongListSelector()
        SelectionChanged += LongListSelector_SelectionChanged;

    void LongListSelector_SelectionChanged(object sender, SelectionChangedEventArgs e)
        SelectedItem = base.SelectedItem;

    public static readonly DependencyProperty SelectedItemProperty =
            new PropertyMetadata(null, OnSelectedItemChanged)

    private static void OnSelectedItemChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
        var selector = (LongListSelector)d;
        selector.SelectedItem = e.NewValue;

    public new object SelectedItem
        get { return GetValue(SelectedItemProperty); }
        set { SetValue(SelectedItemProperty, value); }

If you are going to recompile the toolkit, than don't forget to get the latest sources from codeplex. There are some new fixes checked in in the past few days.

If you have any question regarding this blog post or another related thing, feel free to contact me via the comments, the contact form or twitter.

Did you like this? Share it:
Tagged as: , , 2 Comments