Elmish.wpf: Design time model won't display data consistently when using ViewModel.designInstance

[BentTranberg]

I'm trying to use ViewModel.designInstance to display a design time model, but for most of the time the designer in VS won't display the design time data, but instead just shows the user control as if no design time model is in use.

This is the repo with the solution : https://github.com/BentTranberg/ExploreElmishWpf
(I'll have to learn how to supply a link to a specific revision.)
And it's the CounterPane model.

I also use an alternative design time model, which works reliably all the time. This code snippet shows both models, and the code comments shows the corresponding XAML.

    // d:DataContext="{x:Static vm:CounterPane.designTimeModel}"
    let dtModel = { Count = 3; StepSize = 7 }
    let dtBindings = bindings ()
    let designTimeModel = ViewModel.designInstance dtModel dtBindings

// d:DataContext="{d:DesignInstance vm:CounterPaneDesignTimeModel, IsDesignTimeCreatable=True}"
type CounterPaneDesignTimeModel() =
    member val Count = 4 with get, set
    member val StepSize = 8 with get, set

I have found a silly way to trigger the display of the correct data. If I write e.g. a "z" in a very specific position, like this, in the XAML file in VS, then instantly the number 42 is displayed as Counter value.

d:DataContext="z{x:Static vm:CounterPane.designTimeModel}"

I know 42 is supposedly the answer to the Ultimate Question of Life, the Universe, and Everything, but honestly if somebody is joking with that number it's not me.

Then if I remove that "z", the correct numbers - 3 and 7 - are displayed.

But when I work on, the numbers will soon go away again at some point.

Also, if I alternately paste the two different XAML snippets into the XAML file, the corresponding data will display correctly. But only use of CounterPaneDesignTimeModel is sure to display the numbers permanently while I work on.

I've had this issue in my business project for years, and it's part of the reason why I chose to use classes as design time models.

[TysonMN]

I will take a look.

In general though, my impression is that the XAML compiler and the design time are slightly buggy. When I can't get the design time to display the design time data, one of my troubleshooting steps is to

1. commit all working changes,
2. close Visual Studio,
3. in a git bash terminal, execute git clean -fdx (essentially deleting anything in the repo but not committed),
4. open Visual Studio, and
5. build.

I recommend trying that when the design time isn't working.

[cmeeren]

I have also experienced design-time data to be buggy, though I have generally managed to get it working (when using .NET Framework, not .NET Core 3). You can try to disable and enable "Project Code" in the designer (one of the small buttons below the design surface).

I don't think it works at all in .NET Core 3.0 because it requires Project Code to be enabled, and I haven't seen any support for Project Code in the .NET Core 3.0 XAML designer.

You can also try rebuilding. That has helped me on occasions. (Again though, in Framework, not Core).

[cmeeren]

(I'll have to learn how to supply a link to a specific revision.)

Wherever you are in your repo on GH, press Y on the keyboard to make the URL point to the commit you're effectively viewing.

[TysonMN]

Yep, my investigation agrees with @cmeeren. Your design time works if you just change your target from netcoreapp3.0 to (say) net472.

[cmeeren]

I'll add a note to the readme.

[BentTranberg]

Yes, same here - works with net472 as target framework. I actually had to stop VS and delete .vs, obj, bin to make it work after changing target.

I suspect this can be a valuable repro for some other team. Not sure which team, though.

Thanks for looking into it. Agree to close, but I'll let you know if I notice any improvement.

[BentTranberg]

@cmeeren, you wrote you didn't think it worked at all in .NET Core 3.0, but as I explained it does - I do see the correct numbers with some acrobatics - but it appears to be rather buggy, as @bender2k14 suggested.

[cmeeren]

Oh, I see. I'll have another look.

[cmeeren]

The reason you get 42 is because you set the (invalid) DataContext to a string, whose Count happens to be 42 (with that extra character).

A workaround seems to be to just remove and re-add the line (e.g. delete and undo).

In any case, this actually seems to be working, with the workaround. I'll update the readme.

[BentTranberg]

No, it doesn't work permanently by removing and re-adding the line. The problem will come back quite quickly. I've experimented a lot with this.

[cmeeren]

Sorry, I was unclear; yes, the workaround must be done as often as needed. On that topic though: I noticed that I had to redo the workaround each time I compiled. I expect it's also required when opening a new XAML file. Are there other situations it's needed? Most importantly, it is needed while actively working on an open XAML file? I tried making a simple adjustment (removing a control) and it seemed to continue working without requiring redoing the workaround.

[BentTranberg]

Right. I find it easier to just type that "z" and remove it, as explained in my first post. But using net instead of core during design is even better I feel, as long as the project's source permits. And then there's the possibility to use that alternative design time binding. Btw, I'm investigating if that can be tweaked to use the right model in some way.

[TysonMN]

I actually had to stop VS and delete .vs, obj, bin to make it work after changing target.

Oh, yea. I forgot to include that in my sequence of troubleshooting steps. I edited that comment to include closing and reopening Visual Studio.

[cmeeren]

Readme updated again.