2

As a C# developer my solution (*.sln) and project (*.csproj) configuration files are rarely a problem and Visual Studio (VS) manages things well. Result is I am largely unaware of this essential plumbing.

But now learning F# and Elmish.WPF I discover VS has problems with my configuration.

I have forked Elmish.WPF here: https://bitbucket.org/fandco/elmish.wpf/src/master/ and my questions pertain to two (2) branches of this repository built and run in Visual Studio 2019 v16.9.4, .NET Framework v4.8.04084, in Win10 (v 21H1).

That fork of Elmish.WPF has all my .NET configuration ignorance in full view. ;-)

Branch master is untouched and C# project SingleCounter is the startup project and it runs.

Relevant here are HEAD of branches:

  • RestoringFandCoExperiments - config error in ../src/Samples/Ztest/MainWindow.xaml
  • Ztest_and_ZtestDotCore_works - runs ../src/Samples/Ztest just fine.

The error in branch RestoringFandCoExperiments with Ztest (C# project calling the F# Elmish.WPF project) in MainWindows.xaml is ….

QUESTIONS:

  1. Why cannot I include the F# project Simple.Core into a C# project Ztest as I attempt to do in branch RestoringFandCoExperiments (see picture above)?

  2. Why must Ztest and Ztest.Core share the same name prefix (Ztest) even though they are separate projects?

  3. Perhaps this comes down to my not understanding something fundamental about CLR namespaces and how to specify them when connecting C# and F# projects?

Thanks!

rfreytag
  • 955
  • 1
  • 8
  • 24
  • 1
    In that screenshot it says assembly=SingleCounter.Core, but it should most likely be the same as the namespace. – Bent Tranberg Jul 07 '21 at 18:13
  • 1
    Why do you fork Elmish.WPF instead of just creating a new solution, and use Elmish.WPF from NuGet? That would be much tidier and simpler, in my opinion. If you're interested, maybe I'll make an answer with a recipe explaining that approach. – Bent Tranberg Jul 07 '21 at 18:16
  • 1
    @BentTranberg - To question 1, I am trying to reference the assembly comprised of SingleCounter.Core. What I want to do is not have to have the F# project be subordinate to the C# project. To question 2, I forked Elmish.WPF so that if I make useful changes I can contribute them back to the parent repo. – rfreytag Jul 07 '21 at 19:32
  • 1
    That nr 2 is certainly a good reason. Back to 1, I don't understand why you are trying to reference a namespace Elmish.WPF.Sample.Ztest in the assembly SingleCounter.Core. If you are not familiar with WPF, that would explain it, and if so I can tell you that the vm= thing is not for having one project reference another, but just for defining vm locally, and the namespace and assembly will usually be the same, or nearly the same. The referencing of projects are always in the project files. – Bent Tranberg Jul 07 '21 at 19:46
  • 1
    The structure we always use, is that there's one C# WPF exe-project that references another F# library project. That is the most practical organization, because it easily allows WPF design time models to be written in F#. – Bent Tranberg Jul 07 '21 at 19:49
  • @BentTranberg - it absolutely is the case that I do not understand how WPF is organized. Right now it seems a lot like spellcasting. :-) If there is a concise document explaining exactly how I am to cast these spells I'd be grateful for the pointer. – rfreytag Jul 08 '21 at 00:14
  • 1
    I am the maintainer of Elmish.WPF. Instead of reading about WPF as a whole, we can help you learn what you need to know in order to contribute your improvement. Do you have a specific improvement in mind? – Tyson Williams Jul 08 '21 at 12:13
  • 1
    @TysonWilliams thank you for offering support. My goal is creating an Elmish.WPF ‘Sample’ that anyone can post to the Microsoft Store (after changing its name of course). This would show Elmish.WPF as equal to any other solution delivery platform. – rfreytag Jul 11 '21 at 15:28
  • 1
    Excellent idea. Definitely let me know if you need or want help. – Tyson Williams Jul 12 '21 at 11:21
  • 1
    One of us could author an answer here on SO, but I haven't so far, because I feel it would fall short of the help you actually need. SO isn't the right forum for the kind of discussion we need to keep going. @rfreytag, how about instead you create a repo on GitHub for that sample, and create issues in that repo for any questions you have? You can find me (and others) on GitHub and F# Slack. – Bent Tranberg Jul 12 '21 at 12:43
  • @TysonWilliams Thank you, when I have something rough here I will merge my changes in with a github fork of Elmish.WPF (Does that fit with your needs?). With regards to my goal: I am concerned that .NET Core 5 won't be compatible with the MSFT Desktop Bridge (used to convert WPF to something the Store will ingest). At that point I will need to downgrade to .NET Framework and I will start asking for help. What is the oldest version of .NET Framework usable with Elmish.WPF? – rfreytag Jul 12 '21 at 15:41
  • @BentTranberg - Thank you - I did get something working. Seems I was tripped up by VS not deleting folders and projects that are 'removed' in the Solution Explorer. The result was that I had files being referenced that in VS did not appear to exist. Add in some confusion about how .NET C# namespaces and F# modules interact and ... well ... I figured it out with a little help from Emacs. I will add my own solution when I have time. – rfreytag Jul 12 '21 at 15:43
  • Elmish.WPF supports .NET Framework 4.6.1 – Tyson Williams Jul 19 '21 at 16:10
  • 1
    It might be easier to release a [Elmish.Uno](https://github.com/xperiandri/Elmish.Uno) app through the Windows Store. See also [this issue](https://github.com/elmish/Elmish.WPF/issues/364). – Tyson Williams Jul 19 '21 at 18:33

0 Answers0