WinRT vs. Silverlight - Part 5 - Defining default style template

See intro blogpost here.

Here's something that's actually NOT different in Silverlight (but it's different from WPF as it has always been).
You declare your style using DefaultStyleKey. This means the code looks like this for Silverlight, WPF and Windows Runtime:

public class MyControl : Control
{
    public MyControl()
    {
#if SILVERLIGHT || NETFX_CORE
        this.DefaultStyleKey = typeof(MyControl);
#endif
    }
    static MyControl() {
#if !SILVERLIGHT && !NETFX_CORE
        DefaultStyleKeyProperty.OverrideMetadata(
            typeof(HoverControl),
            new FrameworkPropertyMetadata(
            typeof(HoverControl))); 
#endif
    }
}

Here is what IS different though: You need to set the build action of \Themes\Generic.xaml to "Content". It won't work without it.
Also note that when you add Generic.xaml to your project, it will also get added to App.Xaml. I assume this is a bug in the current release, but you will have to go and delete this entry, or it won't work.

WinRT vs. Silverlight - Part 4 - Dispatcher

See intro blogpost here.

In Silverlight and WPF you will often use the Dispatcher to return from a background thread to jump to the UI Thread. This is required when you need to update your UI, because you’re not allowed to touch the UI from anything but the UI Thread. The Dispatcher method has changed slightly in WinRT. It’s also now of type “CoreDispatcher”, instead of just “Dispatcher”.

#if !NETFX_CORE
  Dispatcher.BeginInvoke(
#else
  Dispatcher.Invoke(CoreDispatcherPriority.Normal, 
#endif
           (s, a) => { ... }
#if NETFX_CORE
      , this, null);
#endif
   );

WinRT vs. Silverlight - Part 3 - Dependency Properties

See intro blogpost here.

UPDATE Feb. 29, 2012: As hinted at below that this would happen, this blogpost on dependency properties is now outdated. Since the Consumer Preview of Windows 8 released, dependency properties now work exactly like they do in Silverlight and WPF.

---

Declaration of dependency properties has changed in the WinRT. This is a temporary change and will go away when WinRT hits beta, but still good to know if you start prototyping on WinRT today. If you are a control developer this is probably one of the things you would have to change in the most places.

Here’s what the API looks like for Silverlight and WPF for registering a Dependency Property or an Attached Property:

public static DependencyProperty Register(
      string name, 
      Type propertyType, 
      Type ownerType,
      PropertyMetadata typeMetadata);
public static DependencyProperty RegisterAttached(
      string name, 
      Type propertyType,
      Type ownerType, 
      PropertyMetadata defaultMetadata);

And here’s what this currently looks like in WinRT CTP :

public static DependencyProperty Register(
      string name, 
      string propertyTypeName, 
      string ownerTypeName,
      PropertyMetadata typeMetadata);
public static DependencyProperty RegisterAttached(
      string name, 
      string propertyTypeName,
      string ownerTypeName, 
      PropertyMetadata defaultMetadata);

Notice how the PropertyType and PropertyOwnerType is now strings instead of types!

This means you would have to write your code like this to make it cross-compile:

        public double MyDoubleProperty
        {
            get { return (double)GetValue(MyDoublePropertyProperty); }
            set { SetValue(MyDoublePropertyProperty, value); }
        }

        public static readonly DependencyProperty MyDoublePropertyProperty =
            DependencyProperty.Register("MyDoubleProperty", 
#if NETFX_CORE
             "Double", "MyNamespace.MyControl", 
#else
                typeof(double), typeof(MyNamespace.MyControl), 
#endif
                 new PropertyMetadata(0d));

Also note that you don’t use the full type name for the system types. Ie. here you use “Double” and not “double” or “System.Double”.

You could create a few static methods to replace the Register/RegisterAttached methods that will make your code cross-platform, and switch it out just there when this changes. Here’s one example how this could be accomplished (the ‘ToRTString’ method isn’t fully tested though…):

    public static DependencyProperty RegisterAttached(string name, Type propertyType, Type ownerType, PropertyMetadata metadata)
    {
        return DependencyProperty.RegisterAttached(name, 
#if NETFX_CORE
            propertyType.ToRTString(), ownerType.ToRTString()
#else
            propertyType, ownerType
#endif
            , metadata);
    }
    public static DependencyProperty Register(string name, Type propertyType, Type ownerType, PropertyMetadata metadata)
    {
        return DependencyProperty.Register(name,
#if NETFX_CORE
            propertyType.ToRTString(), ownerType.ToRTString()
#else
            propertyType, ownerType
#endif
            , metadata);
    }
#if NETFX_CORE
    private static string ToRTString(this Type type)
    {
        string name = type.FullName;
        if(name.StartsWith("System."))
            return name.Substring(7);
        else
            return name;
    }
#endif

WinRT vs. Silverlight - Part 2 - Code Namespace

See intro blogpost here.

The namespaces in WinRT has changed for all the UI related classes. Generally System.Windows has been replaced with Windows.UI.Xaml, and the rest is the same below that. If we to use the “NETFX_CORE” compiler directive that WinRT projects comes with, the typical default using statements that would compile on both Silverlight, WPF and WinRT would look like this:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
#if !NETFX_CORE
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;
using System.Windows.Shapes;
#else
using Windows.UI.Xaml;
using Windows.UI.Xaml.Controls;
using Windows.UI.Xaml.Data;
using Windows.UI.Xaml.Documents;
using Windows.UI.Xaml.Input;
using Windows.UI.Xaml.Media;
using Windows.UI.Xaml.Media.Imaging;
using Windows.UI.Xaml.Navigation;
using Windows.UI.Xaml.Shapes;
#endif

This is also described in greater detail here: http://msdn.microsoft.com/en-us/library/windows/apps/hh465136(v=VS.85).aspx

WinRT vs. Silverlight - Part 1 - XML Namespace

See intro blogpost here.

For the most part your XAML ports right over to WinRT. However an important change is how you register namespaces from your assemblies.

Here's how you do this in Silverlight and WPF for an assembly "MyAssembly.dll" and namespace MyAssembly.MyNamespace:

    xmlns:local="clr-namespace:MyAssembly.MyNamespace;assembly:MyAssembly"

And similar for namespaces in the same assembly as where the XAML file lives (ie MyAssembly):

    xmlns:local="clr-namespace:MyAssembly.MyNamespace"

In WinRT, you only declare the namespace (never the assembly) and instead use "using" instead of "clr-namespace":

    xmlns:local="using:MyAssembly.MyNamespace"

Unfortunately we don't have #if-def statements in XAML so you can just use compiler directives on your XAML and make it work on both platforms. So until we get that (or Microsoft reverts the above change) you are going to have to duplicate and maintain two sets of XAML. :-(

I actually do like this change, and this is probably how it should always have been, but it's a change that cause a lot of pain for developers trying to reuse their existing codebase. The benefit doesn't seem to pain (from what I understand the Windows team simply didn't like it said "clr" in there, plus they don't have the exact same concepts down in the runtime so the assembly part was left out.)

WinRT vs. Silverlight - Part 0

I recently wrote a blog post series on how to share your code between Silverlight and WPF.

With the announcements of Windows 8 at the //BUILD/ conference and the new Windows Runtime (WinRT) which can be built against using C# and XAML I thought it appropriate to start a new series on how to make your existing Silverlight/WPF code run on WinRT. I'm mostly writing this as notes to myself and hope you will also find them useful. Personally I've already found a lot of issues with porting code over. Not that there are significant changes, but the documentation is very limited at this point, and the gotchas enough to make you waste a lot of time on resolving this. Hopefully this will act as a resource to get it working for you as well. Keep an eye on this post. I'll post new links as I go along learning new things about WinRT.

Generally what I have found is that with respect to XAML WinRT is more compatible to Silverlight than WPF, so expect it easier to use your Silverlight knowledge, and don't try and use WPF XAML features at this point. Things like DataTriggers etc. are not supported, and for the most part, the UI related methods in code are more similar to Silverlight than .NET 4 (note however that non-UI code is closer to the "original" .NET, since this is essentially the same CLR and compiler used).

I won't go into too much detail about what this means for Silverlight and WPF. There's plenty of blogs and newssites that has their (over?)reactions described in detail. This series will really just focus on how to take your existing code and get it running on WinRT.

Click to select a topic below:

  1. WinRT vs. Silverlight - Part 1 - XML Namespace
  2. WinRT vs. Silverlight - Part 2 - Code Namespace
  3. WinRT vs. Silverlight - Part 3 - Dependency Properties
  4. WinRT vs. Silverlight - Part 4 - Dispatcher
  5. WinRT vs. Silverlight - Part 5 - Defining default style template
  6. WinRT vs. Silverlight - Part 6 - Using Tasks
  7. WinRT vs. Silverlight - Part 7 - Making WebRequests 
  8. WinRT vs. Silverlight - Part 8 - What other people are blogging
  9. Coming… WinRT vs. Silverlight - Part 9 - File IO
  10. Coming… WinRT vs. Silverlight - Part 10 – Various CTP bugs…
  11. More…