Elmish.wpf: Include sample with an F# startup project

[TysonMN]

This question on StackOverflow is about how to use Elmish.WPF with an F# project as the entry point.

In PR #249, I just switched all the samples to use the C# project as the entry point in order to enable support for design-time data binding.

Maybe we should have at least one sample that has F# as the entry point.

[cmeeren]

I have nothing against that. I requested the poster come here and describe why they want an F# startup project. I'm curious what the motivation is. It would be nice to know if C# startup projects have some caveats we're not aware of.

[BentTranberg]

I've used C# startup for a long time, and is not aware of anything. For F# startup I know I've had several issues. One of them I believe was about running the application as admin by default, but I'm not quite sure my memory is good. Other issues had to do with resources placed in the startup project, when F#. I can try to recreate these problems if there's an interest, but I guess there isn't.

I'm happy you switched to C# as entry point.

[TysonMN]

I am interested, but don't beat yourself up if it is difficult to reproduce

[awaynemd]

My reasoning for posting the question was to follow as close as possible "Getting Elmish in .NET with Elmish.WPF" by Matt Eland. For the reasoning mentioned above, I can see why this now maybe obsolete. Thanks.

[TysonMN]

For reference: link to Getting Elmish in .NET with Elmish.WPF

[MicaelMor]

When I started using Elmish.WPF a lot of the examples I found had F# as the startup project, so that might be where the issue lies, in fact only remember seeing one mention of having C# as the starting point (think it was on the project documentation).

Personally I moved from an F# starting project which was the "standard" at the time, to C# simply so I could use value converters created in F# on the C#, and ofc as the transition of the samples to C# shows, another big advantage is design time models.

The only issue I have found since then is with calling windows, because the F# project does not inherit the C# project it cannot call them directly, the C# project needs to pass them to F#, but the samples already covers a basic (if not super extendable) way of solving that issue.

[cmeeren]

The only issue I have found since then is with calling windows, because the F# project does not inherit the C# project it cannot call them directly, the C# project needs to pass them to F#, but the samples already covers a basic (if not super extendable) way of solving that issue.

That's right. With two projects, there's no way around that if you want both design-time VMs (XAML needs to reference the bindings) and window support (update needs to know how to create windows). You need that layer of indirection.

You can, of course, define an interface in the F# project with methods that construct all your windows and accept that interface as a parameter to update, and implement that interface in the C# project. That way you reduce the amount of arguments to update, but otherwise it's essentially the same, so do whatever floats your boat.