Differences between Silverlight 4 and WinRT



XML Namespaces

adapted from Morten Nielsen's excellent blog post

Here's how you declare an XML namespace 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"

File I/O

Details here


Networking/Sockets

Details here


Dispatcher

lifted from Morton Nielsen's blog post

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 !WINRT
  Dispatcher.BeginInvoke(
#else
  Dispatcher.Invoke(CoreDispatcherPriority.Normal,
#endif
      (s, a) => { ... }
#if WINRT
      , this, null);
#endif
   );

Using Tasks

Just read this. There is too much code to post here. Thanks for doing the hard work, Morten!


System.ComponentModel

Silverlight 4.0

WinRT

Comments

System.ComponentModel.INotifyPropertyChanged
Windows.UI.Xaml.Data.INotifyPropertyChanged
100% Compatible

System.Windows


The System.Windows namespaces are undoubtedly where you will spend most of your time. You not only have to reimagine your UI, which is great, but you will have to refactor the UI code that you will use. This chart will show you the level of compatibility between the mapped UI namespaces.

Just because the namespace maps does not mean the types are identical. In many cases they are not.
Compatible Classes = The number of classes in WinRT with the same name as classes in Silverlight.
Same for structures, interfaces, delegates, attributes, and enumerations.
Even though the names are the same, the syntax and behavior may be different.

Silverlight 4.0 Namespace

WinRT Namespace

Compatible

Classes

Compatible

Structures

Compatible

Interfaces

Compatible

Delegates

Compatible

Enumerations

Compatible

Attributes

Percent Compatible

Comments

System.Windows
Windows.UI.Xaml
35 of 72
14 new
5 of 11
0 of 3
7 of 10
8 new
9 of 18
3 new
3 new
56/114
49%
Functionality that was previously in FooConverter are now in FooHelper, and work a bit differently. New DispatcherTimer here.
System.Windows.Automation
Windows.UI.Xaml.Automation
18 of 22
N/A
N/A
N/A
8 of 8
N/A
26/30
87%

System.Windows.Automation.Peers
Windows.UI.Xaml.Automation.Peers
25 of 55
24 new
N/A
0 of 1
N/A
4 of 4
N/A
29/60
48%

System.Windows.Automation.Provider
Windows.UI.Xaml.Automation.Provider
1 of 1
N/A
19 of 19
2 new
N/A
N/A
N/A
20/20
100%

System.Windows.Automation.Text
Windows.UI.Xaml.Automation.Text
N/A
N/A
N/A
N/A
2 of 2
N/A
2/2
100%

System.Windows.Browser
N/A
0 of 13
N/A
N/A
0 of 1
0 of 1
N/A
0/15
0%

System.Windows.Controls
Windows.UI.Xaml.Controls
48 of 111
29 new
0 of 2
1 of 2
1 new
4 of 8
3 new
5 of 24
7 new
N/A
58/147
39%
Not supported: Calendar, ChildWindow, DataGrid, DataPager, DatePicker, DescriptionViewer, MultiScaleImage, OpenFileDialog, RichTextBox, SaveFileDialog, TabControl, TabItem, TreeView, Validation, WebBrowser
New Controls: ApplicationBar, CaptureElement, CarouselPanel, FlipView, GridView, GroupItem, JumpViewer, ListView, MediaPlayer, ProgressRing, RichTextBlock, WebView, WrapGrid
System.Windows.Controls.Primitives
Windows.UI.Xaml.Controls.Primitives
14 of 26
8 new
1 of 1
3 of 3
1 new
5 of 5
3 of 3
4 new
N/A
25/38
66%

System.Windows.Data
Windows.UI.Xaml.Data
5 of 11
2 new
N/A
1 of 1
12 new
0 of 2
2 new
2 of 3
1 new
N/A
8/17
47%

System.Windows.Documents
Windows.UI.Xaml.Documents
15 of 20
N/A
N/A
N/A
1 of 1
N/A
16/21
76%

System.Windows.Ink
Windows.UI.Input.Inking
0 of 3
10 new
N/A
7 new
N/A
3 new
N/A
0 of 3
0%
Ink has been totally rewritten. All the classes start with the prefix Ink. There is InkStroke and InkDrawingAttributes, and they are very different.
System.Windows.Input
Windows.UI.Xaml.Input
6 of 29
12 new
0 of 1
1 of 1
1 of 6
10 new
3 of 8
1 new
N/A
11/45
24%
Windows.UI.Xaml.Input defines the input and input event infrastructure for applications and UI elements.
There is another related namespaces, Windows.UI.Input, which "provides support for the Windows input system."
This includes:
  • Touch, stylus, mouse, and keyboard device input.
  • Gesture detection, recognition, and handling.
  • Inertia detection, configuration, and handling.
  • Input contact pointer data.
System.Windows.Interop
N/A
0 of 4
N/A
N/A
N/A
0 of 1
N/A
0/5
0%
There is a Windows.UI.Xaml.Interop namespace but it only has classes for dealing with Microsoft Direct3D and an IHostServices interface that "Represents a service that resolves resources from an application for generalized interoperation scenario consumption."
System.Windows.Markup
Windows.UI.Xaml.Markup
1 of 3
1 new
4 new
N/A
N/A
1 of 3
2/6
33%

System.Windows.Media
Windows.UI.Xaml.Media
51 of 88
5 new
2 of 2
N/A
1 of 2
1 new
12 of 25
5 new
N/A
66/117
56%
There is a Windows.Media namespace that "provides classes for creating and working with media such as photos, audio recordings and videos." There is one class (MediaExtentsionManager) that "registers a parser or codec", and one Interface (IMediaExtension) that "encapsulates the method needed to set the configuration properties on a registered media parser or codec."
System.Windows.Media.Animation
Windows.UI.Xaml.Media.Animation
45 of 45
25 new
2 of 3
0 of 4
N/A
3 of 8
1 new
N/A
50/60
83%

System.Windows.Media.Effects
N/A
0 of 5
N/A
N/A
N/A
0 of 1
N/A
0/6
0%

System.Windows.Media.Imaging
Windows.UI.Xaml.Media.Imaging
4 of 4
N/A
N/A
N/A
1 of 1
N/A
5/5
100%
Also see Windows.Graphics.Imaging which "enables the decoding, editing, and encoding of image files in any format for which a codec has been installed."
System.Windows.Media.Media3D
Windows.UI.Xaml.Media.Media3D
1 new
1 of 1
N/A
N/A
N/A
N/A
1/1
100%

System.Windows.Messaging
N/A
0 of 6
N/A
N/A
N/A
0 of 1
N/A
0/7
0%

System.Windows.Navigation
Windows.UI.Xaml.Navigation
3 of 11
N/A
0 of 1
5 of 6
2 of 3
1 new
N/A
10/21
48%

System.Windows.Printing
Windows.UI.Xaml.Printing
1 of 4
3 new
N/A
N/A
3 new
N/A
N/A
1/4
25%

System.Windows.Resources
Windows.Ui.Xaml.Resources
0 of 1
1 new
N/A
N/A
N/A
N/A
N/A
0/1
0%
Provides only a CustomXamlResourceLoader class
System.Windows.Shapes
Windows.UI.Xaml.Shapes
7 of 7
N/A
N/A
N/A
N/A
N/A
7/7
100%
The only complete namespace between Silverlight 4 and the Windows Runtime
System.Windows.Threading
Windows.System.Threading
0 of 4
2 new
N/A
1 new
2 new
1 new
N/A
0/4
0%
Very different. The Windows.System.Threading namespace only has ThreadPool and ThreadPoolTimer classes, and a couple delegates for handling timer and work item events.
There is a CoreDispatcher is in Windows.UI.Core (not code compatible with System.Windows.Threading.Dispatcher). CoreDispatcher "provides the Windows Runtime version of ICoreDispatcher. Instances of this type are responsible for processing the window messages and dispatching the events to the client."
Windows.UI.Xaml has a DispatcherTimer.





Total
Percent
Compatibility:
52%
393 of the 756 UI types in Silverlight 4.0 Onexist with the same name in WinRT

WebRequest

Things are a bit different now. Again, read Morton Nielsen's excellent blog post on the subject


Resources:


SharpGIS : WinRT vs. Silverlight

http://www.sharpgis.net/post/2011/09/15/WinRT-vs-Silverlight-Part-0.aspx

Migrating a Windows Phone 7 app to XAML

http://msdn.microsoft.com/en-us/library/windows/apps/hh465136