Take the 2-minute tour ×

At the WP2W8 London event yesterday I tried to port an existing WP7 custom control across to WinRT (May 31st Release Candidate version)

This custom control had a property which was declared like:

public IMvxCommand Command
    get { return (IMvxCommand)GetValue(CommandProperty); }
    set { SetValue(CommandProperty, value); }

public static readonly DependencyProperty CommandProperty =
    DependencyProperty.Register("Command", typeof(IMvxCommand), typeof(IconWithTextMenuItem), new PropertyMetadata(null));

private void OnTap(object sender, CantRememberExactEventArgs e)
    if (Command == null)

    if (CommandParameter != null)

No matter what I tried I couldn't get this to bind - the output window debug binding error always reported that the binding could not convert type MvxRelayCommand to IMvxCommand

However, if I changed the IMvxCommand to MvxRelayCommand or ICommand then the binding worked.

The inheritance tree here was MvxRelayCommand inherits from IMvxCommand inherits from System.Windows.Input.ICommand - but I do suspect WinRT may be doing some funky type redirection with ICommand in the background.

Does anyone have any insight into whether IMvxCommand or ICommand dependency properties can be used in WinRT custom controls?

Update - an example project is: https://github.com/slodge/WinRTInterfaceBindingProblem

share|improve this question

3 Answers 3

I think System.Windows.Input.ICommand can be used in WinRT controls. In your example, you may just have to declare the dependency property as a ICommand rather than IMvxCommand.

share|improve this answer
Thanks - I agree - but I actually wanted to use something in the extended interface - puzzled about what is going on here :/ –  Stuart Jun 18 '12 at 22:35
I've +1'd the answer - but also corrected the question a little to include the ICommand info and to include a sample repo - sorry this makes your answer look odd! –  Stuart Jun 18 '12 at 22:43

in WP7 ICommand is in the System.Windows.Input namespace. In Metra XAML its in the Windows.UI.Xaml.Input namespace. It seems you are referencing a library that relies on the WP7 binaries which wont compile.

share|improve this answer
Thanks for the answer. The story of ICommand inside WinRT is a strange one - I can't comment on it in detail because I don't yet understand it... However, you are definitely wrong about "won't compile" - System.Windows.ICommand compiles and runs fine on WinRT - e.g. see github.com/slodge/WinRTInterfaceBindingProblem - and I've been told it has been specifically included as part of MS's efforts to improve code portability. –  Stuart Jun 20 '12 at 8:41
It may compile (my mistake), but a Metro XAML Button will want to bind to a Windows.UI.Xaml.Input.ICommand, which means your implementation wont work –  Dean Chalk Jun 20 '12 at 9:03
Sorry - but that's not the case for portable code. see the series on csharperimage.jeremylikness.com/2012/03/… Also please try running the github sample - ICommand clearly compiles and runs - it's just the intermediate interface that doesn't bind at run time. –  Stuart Jun 20 '12 at 9:09
Your question was to why your code doesnt work. The answer is that its not compatible (and would not participate in any portability - rightly or wrongly). Ive answered your question giving you techncal reasons why it doesnt work. The answer is the correct one –  Dean Chalk Jun 20 '12 at 10:08
As I said in my first comment... "Thanks for your answer". I agree with your observation that ICommand exists in 2 places. However, I'm afraid I can't mark your answer is "correct" this stage... not least because 1. the sample - github.com/slodge/WinRTInterfaceBindingProblem/tree/master/App1 - does not reference any WP7 binaries; 2. because it does compile; and 3. because if I change ICommand in the sample to reference Windows.UI.Xaml.Input.ICommand then it won't compile - see social.msdn.microsoft.com/Forums/en-US/winappswithcsharp/thread/… –  Stuart Jun 20 '12 at 10:35
up vote 0 down vote accepted

In the end I got nothing back from MS on this.

But from the sample, I'm guessing its just a bug that we have to live with:


share|improve this answer

Your Answer


