c# - Portable Class Library ICommand compilation error in WPF -- Not sure how to resolve this appropriately?

Question

Some background information:

• I am using VS 2013
• I created a Portable Class Library (Targets: .NET 4.5/Silverlight 5/Win Phone 8/Win Store 8)
• I implemented the ICommand interface in my class named MyCommand.

MyCommand.cs:

public class MyCommand : ICommand
{
    public bool CanExecute(object parameter)
    {
        throw new NotImplementedException();
    }

    public void Execute(object parameter)
    {
        throw new NotImplementedException();
    }

    public event EventHandler CanExecuteChanged;
}

I found that when I attempted to reference use the MyCommand class in a WPF 4.5 application, I get the following error:

The type 'System.Windows.Input.ICommand' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes'.

I'm not really sure why this is happening, or what I can do to resolve it appropriately. After scouring the internet, I found answers talking about adding a reference to System.Windows.dll 4.0.0.0 in my WPF application. Doing this allows me to compile and run the application, but my IDE complains that:

Interface member 'void System.Windows.Markup.IComponentConnector.Connect(in, object)' is not implemented.

This occurs for my MainWindow.cs class. Is there a better fix than to just deal with this bug so I'm not adding a reference to System.Windows.dll in a WPF application which really doesn't need it? And I say that it doesn't really need it because if I copy/paste the MyCommand class into the Wpf app it works fine. It only has an issue because I am attempting to use it as a portable class library.

---

UPDATE:

It seems that there is more to this than meets the eye. I created a new Wpf Application and used NuGet to reference the MvvmCross solution (since it has an MvxCommand object). When I do this, I get the same error.

David Kean's answer to a similar question suggests that this should be fixed via VS2012/VS2013 and if not, just reinstall/repair. I fully removed my VS installation and reinstalled it from scratch (VS2013) and still have this issue. So, is this truly a bug or did I do something wrong here?

---

UPDATE 2:

I attempted to see if I could assign an instance of the MyCommand class to ICommand: ICommand cmd = new MyCommand(); and received the following error:

Cannot implicitly convert type 'PortableClassLibrary1.MyCommand' to 'System.Windows.Input.ICommand'. An explicit conversion exists (are you missing a cast?)

For some reason the PCL does not seem to type forward the System.Windows.dll [2.0.5.0] ICommand to System.dll [4.0.0.0] ICommand for my desktop application... Ugh!

---

Update 3:

I uploaded my solution so that it is more visible as to what the problem is.

---

Update 4:

I've opened a Microsoft connect ticket on this issue.

---

Update 5:

After calming down from being upset about this not working... and others telling me that they don't get the same "interface" error. I realize that the "side-effect" of adding System.Windows.dll was a ReSharper 8.1 error. I guess it's time to complain to ReSharper instead of Microsoft. sigh

Answer 1

You must add a reference to assembly 'System.Windows, Version=2.0.5.0

The advice is excellent, the message is not that great. Clearly you got baffled by the version number. Right-click your WPF project, Add Reference and tick System.Windows. Which solves your problem.

The missing magic is this line in the System.Windows.dll reference assembly:

  [assembly: TypeForwardedTo(typeof(ICommand))]

Which gets ICommand forward from System.Windows.dll to System.dll

Keep in mind that System.Windows.dll from the c:program files (x86) eference assemblies subdirectory is just a reference assembly. It doesn't contain any code or types at all, just [TypeForwardedTo] attributes. It acts as an "adapter", bridging the gap between different .NET framework platforms. The final executable doesn't actually have a dependency on System.Windows.dll at all.