Stride: Cross-platform build for Xenko projects

[xen2]

Idea is to be able to build Xenko projects (incl. asset compilation) on Linux/macOS.

Some important steps:

• [ ] Remove managed c++ code (esp. FBX/Assimp importers)
• [ ] Find/recompile/remove various native dependencies for Linux/macOS
• [ ] Convert projects to .NET Standard or .NET Core (to decide per project)

This is a necessary step before cross-platform editor

[Kryptos-FR]

Convert projects to .NET Core

.NET Standard should be enough for some of them, see my early attempts in https://github.com/Kryptos-FR/Avalonia.GameStudio

[xen2]

@Kryptos-FR yes sorry that's what I meant, editing

[dfkeenan]

That "cross-platform editor" link doesn't seem to go anywhere.

[SleepyMode]

That "cross-platform editor" link doesn't seem to go anywhere.

It's a link to another issue.

8

[xen2]

Yes my bad, it was broken before (I tried [cross-platform editor](#8) but it made a link on same page with #8 in URL). Fixed it a few days ago.

[xen2]

More detailed steps/progress for .NET Core 3

Runtime

• [x] Update to latest System assemblies
• [x] Convert Xenko.Games and Xenko.Input to use .NET Core 3.0 WinForms & WPF, like on .NET Framework

Compiler tools (.NET Core 3 on Windows)

• [ ] Managed code (Assimp/FBX): if not converted to pure C/C# (cf multiplatform section), we could use new C++/CLI in .NET Core but we need to at least add multi TFM build for both .NET Core and .NET FW (i.e. TargetFrameworks)
• [ ] Review various use of EnvDTE (mostly used for reattaching debugger on child process)
• [ ] Remove WCF code (maybe convert to ServiceWire?)

Compiler tools (multiplatform)

• [ ] Managed code (Assimp/FBX) needs to be converted to pure C/C#
  It might be worth investigating if making a C++ to C# PInvoke converter wouldn't make sense.
  But contrary to most existing solution, idea would be to just wrap C++ class as struct and avoid any kind of complex automatic conversion (little bit like SharpVulkan) to make very lightweight & close to the metal bindings that require no/few custom rules.
• [ ] Rebuild various dependencies (Texture libraries, VHACD, msdfgen, etc.) for Linux/OSX

Game Studio (.NET Core 3.0 on Windows)

• [x] Update RoslynPad to latest version (which supports .NET Core 3.0)
• [x] Recompile QuickGraph and GraphX with support for .NET Standard or .NET Core 3.0
• [x] Migrate from System.Windows.Interactivity to Microsoft.Xaml.Behaviors.Wpf
• [ ] Decide how to get rid of Xceed.Datagrid
• [ ] Either wait until Xceed (other than Datagrid) release .NET Core version (in a few months?) or migrate to something else

[Kryptos-FR]

About QuickGraph, did you see that there is already a fork on GitHub that has still some development getting done?
https://github.com/YaccConstructor/QuickGraph

[xen2]

@Kryptos-FR Yes I was hesitating but didn't want to run into regressions for GraphX and our code.
Also I was hoping GraphX might consider a PR so thought staying with something close to official QuickGraph might help.
Anyway, fine to switch to that version if it works well.

[Kryptos-FR]

@xen2 Makes sense. I was just wondering if forking their repo and starting from their initial releases (e.g. nuget https://www.nuget.org/packages/YC.QuickGraph/3.7.1) could work.

Might be safer to start from something closer to what we have currently though.

[meriaizen86]

Xceed now supports .Net Core 3.0.

https://xceed.com/release-notes/

[makotech222]

@meriaizen86 As discussed in the discord, they removed their datagrid component from the Free version, so we will have to replace the datagrid component with something else anyways.

[Kryptos-FR]

@meriaizen86 They might very well support .Net Core but it is still Windows-only. Xceed is and remains a WPF "extension", so it won't magically support other platforms.