DesignInstance not working in VS2012
I ran into this error myself in VS2013 then found this question. After searching more, I found an answer that helped me solve it.
instead of
d:DataContext="{d:DesignInstance vm:DesignAlertsViewModel, IsDesignTimeCreatable=True}"use
d:DataContext="{d:DesignInstance d:Type=vm:DesignAlertsViewModel, IsDesignTimeCreatable=True}"I was using "...d:DesignInstance Type=vm:..." and that displays the same error described above. As soon as I add "d:" everything works.
Here is the thread I found that helped.
Check if the "Platform target" in your build configuration is set to "AnyCPU". My was set to "x64", so the designer was complaining about the missing type.
VS is running in 32 bit so maybe there is an issue with executing code from 64 bit assemblies.
I found the solution when trying to open my UserControl in "Blend for Visual Studio". It displayed an neat exception to me.
P.S.: After using the accepted answer: Use "d:Type=vm:DesignAlertsViewModel" instead of "vm:DesignAlertsViewModel" my control was visible, but no example data was displayed.
Workaround: Make sure that the design-time data class is in the same namespace as the View itself. Once I moved my DesignAlertsViewModel to the View namespace, both the VS2012 and Blend designer immediately started working with the design-time data.
Update: This is a workaround for now, until I get to the bottom of the issues. However, in my case, this is the only way to make design-time data work consistently. Of course, if you go down this route you change the class names since - clearly - the DesignAlertsViewModel is no longer a view model. It is now simply a POCO containing design-time data. So perhaps AlertsDesignData would be a better name. I'm not overly happy with the fact my design-time data lives under my View namespace, but it works.
I also encourage you to take a look at Laurent's article from MSDN Magazine, April 2013. I like this approach, since it exercises the MVVM pattern a lot more: The design time data service/provider is injected via IOC, so your view models will get "exercised" even at design time.
Update 2: After spending yet another 4 hours on this, I think the jury is still out on which approach is the better: Should we go with simple POCO data classes or the MVVMLight approach, using IOC for design-time data services? The former is simple and requires less code, the latter is more true to the MVVM approach, and exercises the real view models to some degree and could possibly reveal some bugs along the way.
Also, I did have to restart VS a couple of times during my refactoring to the MVVMLight approach - design-time data simply disappeared and came back after a VS restart. However, right now it seems stable enough, and I cannot pinpoint this any further.