Elmish.wpf: Improvements when .NET Core 3.0 released

[TysonMN]

@cmeeren, did you have any improvements planned for Elmish.WPF after .NET Core 3.0 is released?

I can think of two.

1. Multi-target .NET Framework 4.6.1 (net461) and .NET Core 3.0 (netcoreapp3.0)
2. Simplify the csproj files in the samples from ~40 lines (including opaque workarounds) to

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
  <PropertyGroup>
    <TargetFramework>net471</TargetFramework>
    <UseWPF>true</UseWPF>
  </PropertyGroup>
</Project>

per the (Dec 2018) update in this SO answer. Specifically, using a project file containing just those lines is working for me when building with preview 6 of .NET Core 3.0. (P.S. Some sample WPF projects target net461 and some target net471, so I used net471 in my example above.)

In fact, it might be possible to do item 2 now, but I haven't checked.

[cmeeren]

Yep, I've already tried that with 3.0 preview.

1. Will be done as soon as 3.0 final is released.

2. Will be done as soon as 3.0 final is released and VS has XAML designer support (may or may not happen at the same time).

[TysonMN]

It is released :)
https://devblogs.microsoft.com/dotnet/announcing-net-core-3-0/

And it looks like the desired XAML design support is in the concurrently released Visual Studio 16.3

Windows Desktop apps are now supported with .NET Core, for both Windows Forms and WPF (and open source). The WPF designer is part of Visual Studio 2019 16.3.

(This comment is just informational. It is not meant as a suggestion to "hurry up and resolve this issue".)

[cmeeren]

The readme probably also needs updating.

[cmeeren]

Hm, I'm having trouble with multi-targeting. <UseWpf> and <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop"> depend on each other, and since <Project> is above <TargetFrameworks> in the hierarchy, I'm not sure if it's possible to multi-target.

We could have two projects, with files from one being linked from the other, but that would complicate the packaging.

We might consider only supporting .NET Core 3.0 going forward. Migration is very simple and well documented, and I'd guess most Elmish.WPF users (being F# devs and using a niche framework) are used to living on the cutting edge anyway.

Opinions welcome.

[TysonMN]

I was able to get multi-targeting working by following the example in https://github.com/dotnet/wpf/issues/327#issuecomment-460765601. See bender2k14/Elmish.WPF/tree/multi-target.

There are two commits in that branch. The second one gets the multi-targeting working. The first commit removes paket and adds a NuGet package reference to Elmish using a PackageReference tag in the fsproj file.

I still don't understand paket. If I remove the first commit, then the second commit by itself doesn't compile with the single fundamental reason being that it can't find Elmish things (like Dispatch<'msg>). In particular, the compile errors seem unrelated to multi-targeting.

[cmeeren]

Thanks! I didn't know this was possible:

<Project>
  <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk" Condition="'$(TargetFramework)' != 'netcoreapp3.0'" />
  <Import Project="Sdk.props" Sdk="Microsoft.NET.Sdk.WindowsDesktop" Condition="'$(TargetFramework)'=='netcoreapp3.0'" />

I'll have another look at this during the weekend.

Re. Paket: You can read the docs here. It's a package manager just like NuGet, but is more powerful/flexible and comes with a few benefits. It's very commonly used in F# OSS projects. However, like FAKE, it's yet another tool in the toolchain, and I'm usually in favour of using the simplest tooling that gets the job adequately done. I'm not convinced Paket adds much to Elmish.WPF development/maintenance, nor FAKE, particularly since everyone using WPF is likely to be using Visual Studio anyway and since the built script is trivial.

Continuing discussion of Paket etc. in #127. I'd like to get that issue (and corresponding PR) resolved (either way) before going further with .NET Core 3.0 since it may impact/simplify the implementation.

[TysonMN]

Thanks! I didn't know this was possible

My pleasure :) I didn't know this was possible either. I feel like a got lucky because this was the only search result that did anything remotely similar.

In particular, the compile errors seem unrelated to multi-targeting.

Well, actually all the compile errors are all for net461. Probably a moot point though since we seem to be moving away from Paket.

[ChrisPritchard]

Do you need any help with the core 3.0 update? I'm starting a WPF application this month (have already started, but pure C#) and really want to switch to using this. Elmish.WPF was a big inspiration when building my Xelmish framework (Elmish.Monogame, if you will).

[TysonMN]

As I see it, the steps remaining are

1. wait for #127 / #129 (seems like less than 24 hours https://github.com/elmish/Elmish.WPF/issues/127#issuecomment-536880016) and then
2. modify the automated build process so that the NuGet package includes the option to target .NET Core 3.0.

I haven't put any thought into the build process. I am sure that @cmeeren can do it, but I don't know how much work that will be.

[ChrisPritchard]

Its a pity you can't just shift whole cloth to dotnet core, as the MSBuild scripts / new project format get a whole lot simpler. I suppose the 'official' cutoff would be next year, with .NET 5.

[TysonMN]

the MSBuild scripts / new project format get a whole lot simpler.

We will be able to use those. If I understand correctly, those features are available if we use the .NET Core CLI tools in the .NET Core SDK. Projects built with those tools can still target .NET Framework.

Its a pity you can't just shift whole cloth to dotnet core... I suppose the 'official' cutoff would be next year, with .NET 5.

The reason to target older versions of .NET Framework/Core is so the project is useable by more people. After adding support for .NET Core, we could drop support for .NET Framework, but then anyone that wants to use the project also has to use Microsoft's newest .NET implementation.

I think the main reason for dropping support would be if the maintenance cost is high. However, I expect the maintenance cost to be low (since @cmeeren has an automated build process and I expect it won't change too often).

[cmeeren]

PR in #140. Seems they fixed the multi-targeting stuff, so the previously mentioned workaround isn't needed.

[cmeeren]

v3.5.0 is in the pipeline with .NET Core 3.0 support 🚀