Trimming Support

Something to look at wrt .NET6 (see #1415). One benefit of .NET6 is the ability to do a "self-contained" build which packs in all the framework and runtime (so no need for a prereq installer) (see also #1415). This however makes the build much larger. One way to reduce this size is to enable trimming, which removes unused code. (perhaps this might even give us an overall size reduction compared to a framework deployed build?)

However, trimming comes with several limitations:

• Blocked by single-file publishing
  • API incompatibilities for that
  • Would also further improve #2654.
  • May need to disable CETCompat
• Built-in COM marshalling
  • Only used directly in BizHawk.Common, in ShellLinkImports.cs, Win32Imports.cs, and Win32ShellContextMenu.cs. No longer used since 4980725
  • Maybe used in some deps wrapping around DirectX APIs? (DirectSound/XAudio2/DirectInput/XInput/Direct3D9?)
    • DirectSound and Direct3D9 use SharpDX, which targets netstandard1.3/net40/net45, so wouldn't be compatible with trimming in the first place (although it doesn't seem to use built-in COM marshalling, so it probably would work if we just decided to fork it and compile it under net6.0).
    • DirectInput, XInput, and XAudio2 use Vortice.Windows. The version we currently use (2.4.2) targets netstandard20 /net6.0 (although the 3.x versions just target net7.0/net8.0), so it doesn't have that problem. It appears to not use built-in COM marshalling for the most part, but it does seem to use ComImport for IMMDeviceEnumerator (although it doesn't actually have any functions and its only usage is only for using the class's GUID to pass it onto CoCreateInstance, so it might just work regardless?)
  • WinForms uses COM marshalling heavily so WinForms projects can't be trimmed (BizHawk.Client.EmuHawk and BizHawk.Bizware.Graphics.Controls). See dotnet/winforms#4649. Another reason to #4350.
• WPF
  • Not used by BizHawk, but something to keep in mind when looking for WinForms alternatives, as some might just wrap around WPF on Windows (e.g. Eto), and so can't be trimmed.
  • Similarly we might not want to use UI frameworks which wrap around WinForms on Windows for the same reason.
• Reflection
  • Reflection itself can often be made compatible with trimming, although we probably want to move away from reflection wherever possible.
  • Serializers (i.e. Newtonsoft.Json) often can't be made compatible however, but it should be easy enough to move to source generator alternatives (i.e. System.Text.Json).
• Dynamic assembly loading and execution
  • i.e. External Tools, so we can't have External Tools if we do trimming?
  • Perhaps we could rework ApiHawk so it delivers APIs with any native library with a pre-defined C interface which allows them to receive APIs, making external tools language agnostic too (something native exports for .NET tools?)
  • Perhaps there's some workaround here? Can External Tools just package in the .NET framework/runtime code that they need? Would that create some conflict with BizHawk's own self contained framework/runtime code?

Start with the .NET trimming and incompatibility links in the issue, then inspect ShellLinkImports.cs, Win32Imports.cs, and Win32ShellContextMenu.cs. Check the cited WinForms, SharpDX, Vortice.Windows, reflection, serializer, and External Tools concerns. The issue does not define a concrete implementation or acceptance condition, so completion would require establishing a feasible trimming scope first.