Debugging Design-Time WinRT XAML Binding in Blend

One ability that makes developing application with XAML enjoyable is what is known as Blendability (the ability to bind XAML element to design-time data, so a developer/designer can visualize and update UI using Blend or design view in Visual Studio). Although, the design view in Visual Studio is now using parts of Blend, Blend is still a better tool for advanced XAML tasks like creating animation or editing visual states.

To bind design-time data, we can use d:DataContext attribute to create and bind design-time instance.

And you should see the design-time data in Visual Studio design view and Blend.



Once in a while, you might want to be able to see how Blend loads and binds design-time data. You can do that by looking for the Blend’s XDesProc.exe PID  (For Silverlight application, you should find the PID for Blend.exe).


After you get the PID, you can go to Visual Studio, DEBUG –> Attach to Process and select the process with the same PID (i.e., 4404) and make sure you attach to Managed (v4.5, v4.0) code type.


After you attach the debugger to Blend, you should be able to set breakpoints, open the XAML page, and debug your C# code.


I hope this tip helps. Besides watching how the sample data is loaded, you can also watch any code that is run when the XAML is loaded by Blend’s designer.

Full source code can be downloaded here.

Enjoy coding!


Revisit WinRT

Windows Runtime or WinRT was officially introduced to the world together with Windows 8 in BUILD 2011.  At that time, there were a lot of questions surrounding it such as, would it replace Win32, .NET, Silverlight, and so on? It’s almost two years, and I assume everyone has their own answers to those questions.

What is WinRT exactly? It is a new set of COM-based (i.e., every WinRT object implements IUnknown and does refcounting) native APIs on Windows 8. Every WinRT objects implements IInspectable which inherits from IUnknown. The API is defined in WinMD metadata format similar to .NET.


Besides creating modern APIs that is cloud-ready, sandboxed, etc., the design objective of WinRT is to create APIs that is accessible to .NET and JavaScript developers as well. WinRT exposed their APIs to C++, JavaScript, and .NET stacks through projections mechanism.


Windows Store App (formerly known as Metro-Style App)

The only type of applications that can be developed by WinRT are Windows Store apps. That’s why many people including me also use term WinRT app to refer to Windows Store app. However, there is no reason to think that, in the future, Microsoft won’t let developer to use WinRT to develop other kinds of app (e.g., desktop app). WinRT app can be run on both x86 (Windows 8) and ARM (Windows RT).

What does WinRT have to do with .NET?

WinRT app developed using .NET (XAML/C#/VB/F#) is still running on CLR which is the same CLR.dll that runs .NET 4.5 app. However, WinRT app is using a subset of APIs and is using different profiles (similar to .NET or console profile).


Silverlight/WPF/Windows Phone developers will feel at home when they are creating WinRT app although some APIs is missing (e.g., unrelated APIs like ASP.NET, COM wrappers) or moved to new classes (i.e., Reflection) or new namespaces. Like Silverlight, WinRT API is also asynchronous heavy (i.e., if an API can take longer than 50 ms to run, the API is asynchronous).


In summary, WinRT provides single APIs for all language stacks. If you want to squeeze out every bit of performance or don’t want GC to get in the way, C++ (C++/CX or C++ and COM) is closest to the metal and is the obvious choice. If you come from .NET background, C#/VB stacks will get you start quickly. If you come from web development side and prefer JavaScript/HTML, WinRT got you covered too (although you still have to learn WinJS). Finally, interoperability among language stacks are seamless as all stacks can consume WinRT components which can be created by C++ and .NET (Not JavaScript).

Here are some references if you want to learn more about WinRT:

WinRT demystified by Miguel de Icaza (Xamarin)

Underneath the Hood with .NET and the Windows Runtime by Shawn Farkas (MSDN Magazine)

Lap around the Windows Runtime by Martyn Lovell (BUILD 2011)

The Windows Runtime Q&A (BUILD 2012)

Rocky and Billy Introduce WinRT! by Rocky Lhotka and Billy Hollis (.NET Rocks)

Understanding WinRT and Windows 8 for .NET Programmers  by Immo Landwerth (The Hanselminutes Podcast)

How does the new Windows 8 Runtime (WinRT) compare to Silverlight and WPF? (Stackoverflow answer by Pavel Minaev)

A bad picture is worth a thousand long discussions by Doug Seven

.NET and Metro: The Windows Runtime and the CLR on Windows 8 by Jeremy Likness