[Linux/Mac/Windows] Transition from .NET Framework / Mono to .NET 6 ?

[maximilien-noal]

Hello,

Prior to the work on AvaloniaUI (see #810 ), a required step in order to make UltimateDoomBuilder fully cross platform would be to migrate it to .NET 6 (previously known as .NET Core)

.NET 6 is fully cross platform, and there is no need to use Mono.

WinForms still exists for .NET 6 (as does WPF, by the way), so this transition would be potentially rather easy.

Microsoft provides a converter for .CSPROJ files (see this guide for porting) so they use the new SDK style format. This can be done while still using .NET Framework or Mono as a target.

Next, for WinfForms to be available again, the converter should have inserted in the relevant .CSPROJ files the following:

<UseWindowsForms>True</UseWindowsForms>

(see this for more information)

Finally, the TargetFrameworkVersion tag should have been replaced with TargetFramework by the converter, but the value should be manually replaced to 'net60' instead of (for example) 'net462'.

Don't know if there are project-specific requirements on top ?

For assemblies that use Windows APIs wrapped by .NET on that particular platform (I'm not talking about ABI calls to .DLLs, aka P/Invoke), the target framework moniker 'net6.0-windows' should be used.

[biwa]

.NET 6 realistically doesn't work on Windows 7, since it's pretty safe to assume that non-corporate users do not have ESU support. No idea how many people still use Windows 7. According to GZDoom's last survey, which is the best guess we have, about 4.4% of Windows users were using Windows 7 or 8. Guessing from the popularity (or rather lack thereof) of Windows 8 most of those are probably on Windows 7. Not a show-stoppe IMO, but it has to be considered.

That poses a bit of a problem for updating the program (especially through the auto-updater), since doing that update on a Windows 7 system would make the program unusable, and it might also be a problem for newer systems. I think .NET 6 isn't installed by default, is it?

[maximilien-noal]

You could use multi-targeting:

<TargetFrameworks>net472;net6.0</TargetFramework>

It will build a .NET Framework dependent app for Windows, and a .NET 6.0 self-contained app.

This scenario also supported by AvaloniaUI. However, while I believe that the app will run on Windows 7, Windows 7 itself is not supported by AvaloniaUI..

Another approach is to use .NET 6.0 anyway. Sure, it doesn't support Windows 7. But it may still run. However, this has more risks.

If you were building a shared library instead of an app, the Target Framework Moniker netstanrdard2.0 would be perfect, but this doesn't make sense for an app. And when I tried this with AvaloniaUI, the template app just crashed.

If you use the MVVM pattern, you could use WPF for Windows (with UseWPF set to true), and AvaloniaUI for the rest. But this at least doubles the amount of XAML code to write. The rest of the code (ViewModels, Models, etc...) for the UI would be shared, as would be the rest of the layers (shared assemblies, etc). On top of multi-targeting, this is the safest route. Also AvaloniaUI is heavily inspired by WPF, so sharing code between the too is really not a problem.

I think .NET 6 isn't installed by default, is it?

By default, .NET 6 apps are self-contained. So, there is nothing to install. It just works.

[maximilien-noal]

Scratch multi-targeting, this won't work.

The gist is:

• Use .NET Standard 2.0 for shared assemblies
• Use .NET 6.0 for the AvaloniaUI front app
• Use .NET Framework 4.7.2 for the WPF front app
• Share everything possible between the two thanks to the MVVM pattern (there are a lot of MVVM frameworks, but the MVVM Community Toolkit has the advantage of generating at compile time all of the boilerplate code).

[biwa]

Way too complicated. Maintaining two version for both AvaloniaUI and WPF is completely out of the question.

[maximilien-noal]

Completely understandable.

The other option is maintaining only an AvaloniaUI app, and for Windows to require what AvaloniaUI requires.