Problematic dependencies

[YoshiRulz]

If it wasn't obvious, these prevent us from moving to .NET 8 (see #1415).

• FlatBuffers.Core
• GongShell
• Microsoft.VisualBasic
• Newtonsoft.Json
  • WIP: Switch from Newtonsoft.Json to System.Text.Json #3932
  • We also have the option of replacing Newtonsoft.Json with System.Text.Json at any time.
  • The more I learn about Newtonsoft.Json, the more I think we should replace it as soon as possible. See docs supplement.
  • As of 2021-07, System.Text.Json can use Source Generators instead of reflection. (But it could be simpler.)
• NLua
• OpenTK replaced in dev builds from 78f5e75
• OpenTK.GLControl replaced in dev builds from 78f5e75
• SlimDX replaced in dev builds from 78f5e75
• System.Data.SQLite replaced in dev builds from bb96825
• System.Drawing.Common partially replaced in dev builds from 7b644f7—some more usages may be replaceable with Magick.NET, otherwise see System.Windows.Forms
• System.Web
• System.Windows.Forms
  • If we want to change UI framework after .NET 8, Linux will need to stay on .NET Framework and have separate "binaries" (it mostly does already). If we want to do it first, we need to switch UI frameworks.
• Per comments here we can't update Vortice because it dropped .NET Standard support.
  • Yoshi has a fork which downgrades its Vortice.Mathematics dep and re-adds the target, and separately a fork of that library which copy-pastes a bunch of code from the BCL in order to re-add the target. Presumably the maintainer isn't interested in either approach.

re: adopting existing libraries to replace our own code, Yoshi has some notes here. If there's enough interest in that you're welcome to open a tracking issue on GitHub instead.

[YoshiRulz]

So I had a play with this thing (the Windows version works in Mono, who would have guessed) and the situation doesn't look too bad. GongShell, OpenTK 3, and SlimDX all reference System.Windows.Forms, but should work in .NET 6 on Windows. IIRC natt saw that in practice when testing the hammer-and-duct-tape branch. and don't seem to work in .NET 6 on Windows.

In other news, .NET 6 doesn't include WinForms for Linux, even though Mono currently supports it, and they're instead pushing ahead with MAUI (a.k.a. Xamarin.Forms). Given that, my plans for the Linux port are as follows:

• Split the binaries. This is basically done in the hammer-and-duct-tape branch. In effect, the current EmuHawk project becomes EmuHawkMono and a new EmuHawk which targets .NET 6 is created. In practice, the *Mono project files are new, and minimal changes are made to the existing project files.
• Keep OpenTK 3. I think we can use OpenTK 4 in EmuHawk and OpenTK 3 in EmuHawkMono with a bit of abstraction effort.
  • I'm assuming that OpenTK 3 and/or SlimDX works in .NET 6, otherwise OpenTK 4 obviously needs to happen before EmuHawk is retargeted.
  • The OpenTK project has since decided that gradual migration is dumb, nobody would want that, and dropped .NET Standard 2.0 -_-
• Do nothing. The Linux port can keep the ugly-but-functional status quo for a couple of years maybe, until Mono starts being dropped from distros.
  • I'm building Mono from source now, so it can be forever.
• Get tired of doing nothing. WinForms might not be getting removed from .NET, but it's also not getting any better. At the same time, all our library projects are stuck on Standard 2.0, unable to use some of the C# 8.0 through 10.0 language features. To reunify the binaries, we'll first need to decide if we want to switch to MAUI or to a third-party option (I'm aware of Avalonia, Dear ImGui, Eto, and Uno), and then focus on the one framework instead of dividing our efforts.
  • Once the Linux front-end is replaced with one that works on .NET 6, every project can target .NET 6. But, IMO, we should create a new front-end with the expectation of using it on Windows too as having two front-ends is just more maintenance work. Especially when one of them is WinForms.

edit 2022-08-12: I've just been made aware of the ActiveQt library/framework which appears to require choice of Managed C++ or COM? Not sure if Mono supports either.
edit 2024-03-21: Found this thing on HN which I think is ImGui but with vectors? https://github.com/rive-app/rive-sharp

[Sappharad]

• Get tired of doing nothing. WinForms might not be getting removed from .NET, but it's also not getting any better. At the same time, all our library projects are stuck on Standard 2.0, unable to use some of the C# 8.0 and 9.0 language features. To reunify the binaries, we'll first need to decide if we want to switch to MAUI or to a third-party option (I'm only aware of Dear ImGui), and then focus on the one framework instead of dividing our efforts.

The other third-party option that was recommended to me several years ago was Eto, which translates to native options on their respective operating systems (WinForms, WPF, GTK, Cocoa):
https://github.com/picoe/Eto
The API very much resembles that of WinForms, which made it an easy choice back then. Although it seems Eto is still getting active commits, I'm not necessarily recommending it but rather just issuing a reminder that it exists.

I had started a crappy recreation of the WinForms UI in it several years ago, only to abandon it because I didn't want to spend the time necessary to recreate everything and moved back to WinForms before mostly suspending the macOS port entirely.
https://github.com/Sappharad/BizHawk/tree/EtoHawk/BizHawk.Client.EtoHawk
(That last commit from 2018 is actually a problem I ran into later with WinForms and ended up solving, but I don't think it affected Windows.)

[leo60228]

https://github.com/emclient/mac-playground has a port of Mono's WinForms to netstandard2.1. I'm not clear on whether it's compatible with Linux or just macOS, though.

[Sappharad]

That is just for macOS. It’s what I was using for the Mac port after Apple dropped 32-bit support. It won’t help you on Linux

[YoshiRulz]

This seems a good place to put this—.NET Framework 4.8.1 is real and available now, but only for Win10+, and it only includes the promised accessibility changes, not .NET Standard 2.1 support or anything "new". I don't think we should upgrade, and I'm not even going to bother checking if Mono runtime supports it.

[YoshiRulz]

a catch-all works on all OSes would be beneficial for us to have first

I'm increasingly souring on this position. macOS all but precludes that anyway (as does Windows UWP I believe).

[YoshiRulz]

Possibly not the right thread for this:
https://github.com/meziantou/Meziantou.Polyfill is similar to PolySharp, but the list of backports is different. Most relevant is that it includes some extension methods. (PolySharp seems to eschew methods added to existing types—which is fair enough, since the call must be to a nonstandard type when polyfilled i.e. not binary-compatible. But we needn't care about that for our internal libraries, only whether the combined app works.)
Naively adding the dependency in results in a build failure because both trigger for the same polyfills (I'm pretty sure they run in series and the second could detect the first...), but both are also configurable. If it can reduce the amount of backports we have to maintain then I say it's worth a try.