Migrate to .NET (formerly .NET Core)

[nattthebear]

(Going to call it .NET Core here for clarity.)

.NET Core continues to gain new features, simpler and faster APIs, and better runtime performance. Even if MS hadn't formally ended .NET Framework development (which, 4.8.1 aside, they have), migrating is a no-brainer for any project.
Some features of C# rely on runtime support for certain types and are thus unavailable to us.
Along with a dramatically improved JITter, .NET Core has an AoT compilation mode (#3768), which builds upon trimming/DCE (#3767), which builds upon single-file publishing (see also #2441 and #2654).
Other opportunities that .NET Core would give us are tracked in &21. While a lot of the .NET ecosystem targets .NET Standard 2.0, a few only target .NET Core.

Per #2261, WinForms is the last big roadblock to switching. If we split Win/Tux and upgrade to modern WinForms, there are a few breaking changes to look out for, and shiny new async APIs.

[Sappharad]

As another benefit, I think this might be relevant to the post I made yesterday regarding the macOS port: http://tasvideos.org/forum/viewtopic.php?p=479475#479475

Specifically, I'm using an alternative 64-bit implementation of WinForms instead of the 32-bit one that ships with Mono and a custom fork of OpenTK with a modified GLControl to work against the 64-bit implementation. My fork has all of the System.Drawing & System.Windows.Forms references replaced with references to DLLs included with the code.

I suspect that switching to .NET Core 3 might make it easier for me to substitute the WinForms implementation without making invasive changes like I have now. I haven't thought about how yet, but it's probably going to be easier for me to substitute a nuget package than replacing a bunch of references everywhere. And I'm stuck with the bigger binary problem already since I migrated to the Xamarin stuff that will bundle mono into the mac builds.

[YoshiRulz]

It goes without saying that I'm in favour of this (because it will work better on Linux and allows us to use C# 9.0 and above).

---

edit: There was a wall of text here, but it was outdated. See #2260 resolved and #2261 resolved modulo WinForms.

[YoshiRulz]

Possibly breaking changes to WinForms:

• net48 => netcoreapp3.1: MSDN
• netcoreapp3.1 => net5.0: MSDN (first page, check sidebar under Breaking changes by area > Windows Forms)
• net5.0 => net6.0: MSDN (ditto)
• net6.0 => net7.0: insignificant
• net7.0 => net8.0: MS Learn (first page)
• net8.0 => net9.0: MS Learn (ditto)

[YoshiRulz]

Just rebased hammer-and-duct-tape and got the diff looking good (+225/-18). As before, there's a new solution and new projects specifically for Linux, each project including all the source files of its counterpart but targeting net48. The idea being that the branch can be merged without disrupting Windows devs' workflows—I could have instead left the current projects on net48 and added new projects targeting net6.0. Either way, I need help with getting it on par w/ master so it can be merged ASAP.

edit 2021-12-04: .NET 6 now. In my brief testing, the UI was less responsive, and there was a framerate drop in managed cores (SMB1 title screen demo in NesHawk dropped 110 fps -> 100 fps). Unmanaged cores work (I tried Gambatte and Mupen64Plus), didn't try Waterbox. Direct3D and OpenGL both failed.

edit 2025-01-11: Morilli rebased and opened #3745.