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

How to pin Git Shell into the Windows 8.1 task bar

If you are a Windows and GitHub user, you can install GitHub for Windows and be able to do most of the git tasks such as clone, sync (push, pull), and so on. However, sometimes you will need to run git commands directly and Git Shell which comes with GitHub for Windows can be very handy.

Git Shell is actually a msys/MinGW with git and some standard GNU programs (e.g., ssh-keygen) written for windows. Hence, you can use Git Shell with any git repositories like TFS online, Bitbucket, or Heroku.


However, one annoying thing that I found was that although you can pin GitHub and Git Shell icons to the Windows start screen, you can only pin GitHub icon to the task bar.

It turns out that someone already comes up with a small trick to do that. Thank you very much! 🙂

Let’s see how it is done:

1. Go to Git Shell shortcut location.



2. Open the properties window and add something like “explorer” at the beginning of the target field and apply your change.


3. Now you should be able to drag the shortcut icon. Next, open the properties window of the Git Shell icon on the task bar and remove the “C:\Windows\explorer.exe.”


Don’t forget to change the target field that you change in #2 back as well.

And you should be able to use Git Shell for GitHub and any Git repositories! By the way, this trick works on Windows 7 as well (just look for the Git Shell in start menu or on desktop).


How to detect when a user completes changing WinRT XAML Slider value?

Someone has asked me why we couldn’t detect when a user completes changing slider value (via dragging the slider thumb, clicking the slider, up/down keyboard and so on). At first, I was kind of surprise to learn that there is no such thing as a completed slider event.

However, if you think about it, how do you know when the value change event is over? You can’t really know unless you set a specific duration that you will be certain that a user is done with the slider.

So I think the best way to do it is to set up a timer to detect when our user stops interacting with the slider.

Let’s see the code:

Hope this helps!

Hyper for YouTube – An App to rock your YouTube world!

Great app!

McAkins Online


(Looking to get in contact with the Dev of this app. If you are and you’re reading this, contact me via Twitter: @McAkins. I will verify you in the Store, so pranksters don’t need to bother.)

Here is yet another awesome YouTube Player App in the Store. Just dropped two days ago. The thing with YouTube players is that once you’ve seen one, you’ve probably seen them all. Still, there are some subtle differences. It is the extra-mile that a Dev covers that makes the diff between a ‘good’ app and an ‘awesome’ app. So you can place this app in the category of Awesome thus.

This app covers everything you can think of about YouTube: Accounts, Uploads, Comments, Reviews, Subscriptions, Playlists and last and most important, background playing of videos. Yes, most of us, play our favorite bands via YouTube these days, and while playing you want to…

View original post 403 more words

Payload contains two or more files with the same destination path

I was trying to debug why I can’t set the SmallLogoUri and HeaderBackground for Callisto SettingsFlyout with Caliburn.Micro (For more detail, please see my last post, WinRT Settings with Caliburn.Micro).

So I download the Caliburn.Micro from codeplex , add required projects (i.e., Caliburn.Micro.WinRT and Caliburn.Micro.WinRT.Extensions) to my solutions.


When I tried to build the solution, I got the error.

Error    1    Payload contains two or more files with the same destination path ‘Windows.UI.Interactivity.dll’. Source files:
C:\Users\Karlkim\documents\visual studio 2012\Projects\CaliburnSettings\packages\Windows.UI.Interactivity.\lib\win\Windows.UI.Interactivity.dll
C:\Users\Karlkim\Downloads\caliburnmicro-ae25b519bf1e46a506c85395f04aaffb654c0a08\src\packages\Windows.UI.Interactivity.\lib\win\Windows.UI.Interactivity.dll    CaliburnSettings

To resolve the issue, just change the “Copy Local” property of Windows.UI.Interactivity in the WinRT project () to False.


And you should be able to build the solution successfully now!

WinRT Settings with Caliburn.Micro

One advantage of developing WinRT applications is that we can implement standard Windows 8 contracts such as Search, Share, or Settings that provides consistent app experience to our users.

Most applications, Metro App or not, allows user to view or modify application settings. In WinRT development especially with XAML/C# , it’s not straight forward as we have to create our own settings flyout as well as handle everything from creating SettingsCommand to closing our settings area. Callisto, a control toolkit for Windows 8 XAML applications created by Tim Heuer, does help by providing a way to create SettingsFlyout and SettingsManagement.

It’s even easier if your app is following MVVM pattern and using Caliburn.Micro as it provides an integrated way to implement Settings charm. Indeed, Caliburn.Micro also utilizes Callisto controls.

You can get Caliburn.Micro using NuGet (Callisto is also installed if your app have not installed it already).

I won’t get into detail about how to have your app implement MVVM pattern with Caliburn.Micro. Here are some links that should help you get started.

In this post, I will add About option into the Settings charm. I start by adding AboutViewModel and AboutView into the project. Caliburn.Micro utilizes convention over configuration pattern, so I can just create the view and view model, and let Caliburn.Micro links them together without explicitly specify it.

The code is pretty simple.

After we have View and View Model ready, we can just register the setting service and About command with AboutViewModel.

Let’s see the app in action:




That’s it. You don’t need to worry about creating a popup wrapping user controls and handle their life cycle. Implementing settings charm won’t pollute your nice and clean MVVM WinRT app anymore 🙂 .

Note: if you want to customize the background header of the setting dialog, you can do something like this.