-
-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Include sample with an F# startup project #261
Comments
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. |
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. |
I am interested, but don't beat yourself up if it is difficult to reproduce |
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. |
This comment has been minimized.
This comment has been minimized.
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. |
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 ( 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 |
This issue is subsumed by issue #325. |
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.
The text was updated successfully, but these errors were encountered: