I’ve had this problem for as long as I can recall. My page inspector in Visual Studio 2012 never worked… which normally would have been ok, since I could always do the old-school edit+save+refresh routine… but when you know that the feature exists, it is a bugger that it doesn’t work.
I tried everything, from disabling all my extensions and add-ons, to hooking up a debugger to my devenv process… to the obvious google-and-bing-fu manic searches… but got nothing.
If you check your ActivityLog.xml, you will see that Page Inspector is blowing up with a NullReferenceException… no surprise there.
After installing VS2013 I hoped that all of this would go away, but I got the same error.
Finally, I had the great brain wave of setting Internet Explorer as my default browser and restarting Visual Studio (I’m a chrome user).
…and voilà… page inspector finally works :(
One would think that by this time, this whole thing about being wired-in to Internet Explorer was a thing of the past… clearly it is not.
A developer wrote an ICommand implementation in a .NET Portable Subset library, and tried to include this in a WPF project.
This resulted in MSBuild asking him to include System.Windows v184.108.40.206
At first this seems wrong, since ICommand now lives under the System assembly. So I used ILDasm to look at the Manifest of his generated assembly, and find a reference to System.Windows v220.127.116.11
The first reaction of the community was to complain and say that there should be a TypeForwarder for ICommand in System.Windows, yet this is not totally correct, since they were thinking of System.Windows v18.104.22.168, not v22.214.171.124.
..and in fact, if you disassemble System.Windows v126.96.36.199, you do find a correctly implemented TypeForwarder for ICommand.
But the problem is, that since the manifest declares v188.8.131.52, MSBuild goes to look for ICommand in System.Windows, finds that it is not referenced, and complains.
This is correctbehaviour.
The solution to this is a bit tricky, and requires one to understand how MSBuild pieces things together.
First of all, although if we ‘Add Reference’, Visual Studio only shows us assemblies targeting our framework, this does not mean that we cannot directly reference older assemblies.
So, the first step, is to find v184.108.40.206 of System.Windows (you can find it in the .NET Portable folder), and copy it to our local lib folder.
Why do we do this? Simple, because if we are targeting .NET v4 or other, we cannot assume that the user has all the other assemblies already.
Once we do this, we can add a direct reference to System.Windows v220.127.116.11
But lo and behold, MSBuild is still not happy… now he complains that we have TWO ICommand implementations, one in System v18.104.22.168 and one in System.Windows v22.214.171.124, and both under the same namespace.
So what do we do?
MSBuild has a concept of ‘aliases’. Every assembly falls under one or more aliases, and by default, all assemblies fall under the ‘global’ alias.
So what we do to solve this, is that we remove System.Windows from the global alias, and give it a custom alias… like so:
Select the System.Windows reference in your project, and select properties (or hit F4)
In the ‘Alias’ property, remove ‘global’, and add a custom alias, ex. ‘SomeAlias’
Next, reference your type using this alias… this telling MSBuild that you want THIS implementation, and not the one in System
do this by defining the ‘extern alias SomeAlias’ outside your class, and referencing it directly… like so
And voila, problem solved, we can now compile happily (although it looks like ReSharper does not know about aliases, and will complain)
For reference, the StackOverflow post can be found here.