Multi-targeting, phase 1

[YoshiRulz]

diff without first 2 commits

(I'm sure Meziantou.Polyfill would take the TryAdd polyfill if I opened a PR, but it's 10 LOC so that wouldn't meaningfully shrink this diff.)

I've pulled in the System.Reflection.Emit package, but again I think it's only used in one file. What is this vendored component, and is there an alternative which doesn't do IL-weaving?

[binary1230]

The auto factory thing is something we could remove, it registers class names based on a string. I think we're using it in one place only during service registration.

It's part of LightInject, which is what we use to instantiate a lot of the classes in the code.

What's the end goal here, I'm a little unfamiliar? Can we run winforms on Linux if targeting .net standard 2.0?

[binary1230]

https://github.com/DizTools/Diz.Ui.Winforms/blob/f550b45e81d914cdf130e1c0396878a53b277cb0/Diz.Ui.Winforms/DizUiWinformsCompositionRoot.cs#L17 those strings there match up to method names in IViewFactory, so it's probably using reflection for that. But it's a minor thing that could be done in other ways

The main point with light inject is to let the underlying non-UI libraries create views from interfaces without having to reference the specific UI lib (like winforms).

The idea being that basically everything except diz.ui.winforms doesn't ever directly reference the winforms assemblies and is (in an ideal world) as cross platform as possible

[YoshiRulz]

End goal is something like https://github.com/YoshiRulz/DiztinGUIsh/tree/mono-hack. Mono runs assemblies which have been built for .NET Framework <= 4.8—including most of WinForms, though it's far from a pixel-perfect reimplementation. And .NET Core WinForms looks the same as OG WinForms at the call-sites, so multi-targeting just works.
There's not really a reason to target the smaller .NET Standard for internal libraries, I just did it out of habit, and with polyfills it's almost identical to .NET Framework less WinForms anyway.

The IL weaving shouldn't be a problem for Mono. I only brought it up because it's gross and it seemed like a similar situation to the IX.Observable usage.

[binary1230]

just FYI, the code doing the emit here:
https://github.com/DizTools/Diz.Ui.Winforms/blob/f550b45e81d914cdf130e1c0396878a53b277cb0/Diz.Ui.Winforms/DizUiWinformsCompositionRoot.cs#L17

Is part of the LightInject library, which is part of a pattern called "AutoFactory" (though.... it seems to have been removed in the latest LightInject?)

it's included as an extension that I dropped into.... Diz.Core/vendor/LightInject.AutoFactory.cs. I think it's now a Nuget package in LightInject 7.0

It's also superflous and we can easily do these service registrations another way.

The idea is simply, you can define an interface like this (which we do in Diz currently)

public interface IViewFactory
{
   // bunch of views here
    IImportRomDialogView GetImportRomView();
    IProgressView GetProgressBarView();
    ILogCreatorSettingsEditorView GetExportDisassemblyView();
    ILabelEditorView GetLabelEditorView();
    IMainGridWindowView GetMainGridWindowView();
    IFormViewer GetAboutView();
    IRegionListView GetRegionEditorView();
}

that's defined in a non-platform-specifc place (like Diz.Controllers, which is not a dependency on Winforms or any other specific GUI)

then, these can be registered by platform-specific code (like Diz.App.Winforms, or Diz.App.Avalonia, or Diz.App.Eto, or whatever you want)

so for instance, when the Winforms app runs, it calls this to register the winforms-specific class MainWindow:

serviceRegistry.Register<IMainGridWindowView, MainWindow>("MainGridWindowView");

and then given an instance of IViewFactory viewFactory, you can call this from non-winforms code:

IViewFactory viewFactory = ....; // get from somewhere
var mainWindow = viewFactory.GetMainGridWindowView();

The entire point of lightinject (mostly) in Diz is to decouple all the GUI stuff from all the other libs. There used to be no separation, but now it's mostly separated so any important logic is done in a Controller (or somewhere else), along with a non-platform-specific View interface, and the platform-specific stuff implements the specific View interfaces. so we might have a MainWindowWinforms view vs a MainWindowAvalonia view vs MainWindowEto

The lightinject and dependency inversion stuff and platform separation in Diz is ....... half-there. I half-regret putting it in but, I keep finishing the implementation as I go. it's... a small mess, sorry : )

[binary1230]

Everything NOT in the UI should theoretically be able to run natively in whatever the latest real .NET version is on any platform. it's just the UI that's tied to the specific platforms. (and maybe some of the stuff you're touching on here like the path handling)