16

I just spent several hours on an issue when using VS2012, WPF 4.5 and design-time data, specifically the DesignInstance attribute.

Goal: I wanted to have design-time data support in my WPF project (MVVM-based), both in VS2012 and Blend, and I could not for the life of me make the MVVMLight approach work consistently.

So I tried to change to "just" using the built-in support for design-time data, using the markup extension provided with Blend.

Problem: Consider the following code:

<Window x:Class="Nova.View.AlertsView"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:local="clr-namespace:Nova.View"
        xmlns:vm="clr-namespace:Nova.ViewModel"
        mc:Ignorable="d"
        DataContext="{Binding Alerts, Source={StaticResource Locator}}" 
        d:DataContext="{d:DesignInstance vm:DesignAlertsViewModel, IsDesignTimeCreatable=True}"
... />

Both VS2012 and Blend reports "the name DesignAlertsViewModel does not exist in the namespace clr-namespace:Nova.ViewModel", even though intellisense resolves it just fine, and you have checked a thousand times that the namespace and class name are both correct.

Thomas
  • 558
  • 4
  • 14
  • 1
    I've had similar problems before and think I had to comment out the problematic line and compile the assembly, then it works fine when you add it back in. – AlSki Jul 05 '13 at 10:29
  • My only other suggestion is using the full syntax and include Type= i.e. d:DataContext="{d:DesignInstance Type=vm:DesignAlertsViewModel, IsDesignTimeCreatable=True}" – AlSki Jul 05 '13 at 10:30
  • Thanks, @AlSki, I _did_ try the full syntax, but with no luck. Design-time data appears initially, but eventually stops working (simply disappears with no errors given). I've update my "solution" below to be a "workaround", and will do some more digging into this. – Thomas Jul 08 '13 at 07:03
  • I'm having issues with this in my View. Have you found something that works better now, a year later? – Zack Aug 18 '14 at 14:24
  • @Zack: First, I'm on VS2013 update 3 by now. Second, we have been using the "POCO approach" I describe below ever since, and have found it to be just fine for us. No, it's not a design-time version of the exact same ViewModel, but it still achieves the goal of not having to build AND run the entire app, just to see a UI change. That really has saved us quite some time by now, we believe. So design-time data is definitely a great thing, and I can only recommend using it - one way or another - when building larger WPF apps. – Thomas Aug 21 '14 at 07:27
  • After intermitently seeing design time sample data, I have reached the following conclusion: everytime I rebuild the assembly which contains sample data, I had to close and reopen my solution to get my design time sample data back. I have also, witnessed this behaviour on Blend 2013. – Julio Nobre Sep 20 '14 at 03:33

4 Answers4

30

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.

https://stackoverflow.com/a/21690404/2892400

Community
  • 1
  • 1
IntStarFoo
  • 765
  • 8
  • 14
  • This, combined with @al-bex 's answer, solves it. Too bad the XAML editor black-boxes all errors. – Oyvind Jan 16 '19 at 11:24
8

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.

al-bex
  • 666
  • 1
  • 9
  • 24
  • 2
    Yes, setting x86 is working for me. Thanks a lot!. – Juanin Aug 19 '15 at 17:28
  • I simply opened the "configuration manager" and visual studio refreshed... It works now. – Finickyflame Mar 22 '17 at 13:56
  • This issues persists as of VS2017 15.5.6. Consider upvoting the issue: https://developercommunity.visualstudio.com/content/problem/63741/the-xaml-designer-cannot-resolve-types-from-the-cu.html – Terrence Feb 15 '18 at 20:07
7

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.

Thomas
  • 558
  • 4
  • 14
  • (no downvote bro) That really isn't the solution. You don't *have* to do this, I can guarantee that. There probably is something else going on. Design time data can be very touchy, and doesn't report errors well. I'd suggest moving your VM back to its proper place, cleaning your solution, restarting VS, and trying again. Realize that there's another process running the design surface (XDesProc.exe) that is imho buggy. It needs to reference your latest built assembly. If its got an old version, you can encounter this issue. –  Jul 05 '13 at 12:59
  • Ok, fair enough, I've updated my own answer to clarify that should be considered a workaround for now. However, I still think that for some, this may be a completely fine approach - simply having POCOs with design-time data (I'm aware that such POCO is no longer a view model. See my comment on naming). I agree that the designer seems buggy - which makes it hard to give any "guarantees" as to how to make things work, IMHO ;-) If you have experience with a better approach that works consistently, please let me know! – Thomas Jul 08 '13 at 06:58
0

I've found that DesignInstance is not working in my .NET 3.5 and .NET 4.0 projects, whereas it works in >= .NET 4.5 project (the projects are the same, they share the same files by using links).

Maxence
  • 12,868
  • 5
  • 57
  • 69