'Could not find part of a path' errors in Visual Studio 2013 that don't appear in Visual Studio 2010

Question

I've recently had the misfortune of being upgraded to Visual Studio 2013 at work and it has been nothing short of a nightmare. Ever since upgrading my large scale WPF application to .NET 4.5.1 in Visual Studio 2013, I've been getting mysterious 'fake' errors appearing in the Error List. Sometimes they even stay after a Clean and/or Rebuild, but they not really true errors. Here is an example where you can see that I have just cleaned, but still the errors remain:

I want to be clear here... there is no problem with this view model and I can build that project, or the whole solution without (real) error and the application also runs perfectly:

Furthermore, when running the application there is also a problem that it has with image paths. My images are all displayed perfectly, but I get these 'fake' errors again:

Note that the listed paths are even displayed incorrectly:

C:\Midas;component\Images\Actions\Delete.ico

In the UI, it is referenced like this:

<Image Source="/Midas;component/Images/Actions/Delete.ico" ... />

I'm not really sure whether these fake errors are caused by changes made to Visual Studio 2013, or by changes made to the .NET Framework in versions 4.5, or 4.5.1. I'm hoping someone can shed some light on this for me, because I'm about ready to downgrade to .NET 4.5, just so I can use Visual Studio 2012 instead.

Answer 1

It looks like you're using the /{Assembly};{path/to/Image} construct without the pack:// uri prefix. The editor is warning you that it can't find the file because it doesn't really understand the Uri (until the application is actually built). It'll be defaulting to looking on the file system and trying to prefix it with file://, which of course results in a relative uri to the working directory of the Visual Studio process.

I suspect that if you explicitly include the pack:// uri prefix, that the editor will stop complaining.

pack://application:,,,/Midas;component/Images/Actions/Delete.ico

That way the designer will just know that it should not be trying to look for a file:// location.