Now that we have successfully ported our Windows Phone Chart to WinRT I will share some tips and tricks about the whole process and what is different compared to Silverlight and WPF regarding code behind and XAML compilation.
Code behind namespaces
Both logical and visual tree hierarchies of Dependency Objects now reside in new namespaces and the old ones like System.Windows.Controls do not exist. This automatically breaks any existing C#/VB code.
SL/WPF UI namespaces in WinRT are replaced by new ones
The good news is that this problem may be solved by a simple “Replace in files” command for each conflicting namespace. If the codebase is meant to be common (shareable) among different platforms – as in our case – then we may use conditional compilation symbols.
Using conditional compilation we may reuse one codebase among SL/WPF and WinRT
There are changes in the way namespaces are declared in XAML. The SL/WPF way is:
Namespaces within the same assembly where the XAML file resides
Namespaces coming from other assemblies
The WinRT model does not include the assembly regardless of where the type is coming from (it will look it up from the known types in the Application Domain):
Although this model is cleaner IMO, it is a breaking change and the bad news is that there is no conditional compilation in XAML so that we cannot reuse same resources targeting both SL/WPF and WinRT. Still, there are solutions – for example a custom pre-build step (or MSBuild task) that processes all XAML files and updates the namespaces.
The signature of registering dependency properties in WinRT is changed. It accepts String rather than Type parameters. This however is most probably a temporary change and the signature will be the same when the framework hits BETA. Still, if you are experimenting with the platform it is good to know how to translate these:
DependencyProperty.Register signature requires string parameters
You have two options here – either update your code property by property or use a helper method that will perform the actual registration:
A helper class that handles the conditional registration of dependency properties
Now you may simply “Replace in files” all occurrences of DependencyProperty.Register with DPExtensions.Register. You may already wonder – why do we need that “magic” with removing the “System” prefix from primitive types. Well, most probably this is a bug in the early bits of WinRT and this bug will go away once the BETA is out – thanks to Morten Nielsen for figuring it out.
The OnApplyTemplate method
Almost each custom control in SL/WPF will override its OnApplyTemplate method and perform additional logic there. In WinRT this method is no longer overridable (virtual). Luckily there is a virtual OnApplyTemplateCore method that does the same job. So, the solution here will be:
TypeConverter missing (Oh, no!)
To my surprise there is no System.ComponentModel.TypeConverter class or any equivalent:
Type converters are fundamental building blocks for implementing great user experience. According to Microsoft there is no new alternative to these but they are looking into it (fingers crossed).
Well, these are most of the compilation problems we were facing during the migration. Although this part was pretty straightforward, there were several pitfalls that we step into once we tried to run the chart for the very first time. But I will tell you about these problems in my next post to come – make sure you do not miss it :)
Georgi has 15 years of experience in multiple software technologies. Ten years ago, he joined Telerik, later acquired by Progress, and he has set up and led multiple products and teams since. His latest endeavor is building a product that adds the Progress value into the augmented and virtual reality development workflow.
Subscribe to be the first to get our expert-written articles and tutorials for developers!