Godot: Mono/C# support for UWP

[akien-mga]

After Android (#20267), iOS (#20268) and HTML5 (#20270), we'll likely want to bring Mono/C# export support for UWP. This issue is to discuss what needs to be done and the progress.

CC @neikeq

[neikeq]

This may already be working. Has anyone tried it?

[vnen]

I can try testing on Windows. Ideally this should be tested on an ARM device and on Xbox One too, but I don't have any of these devices.

[vnen]

Eh, I can't even build with the Mono module enabled...

[vnen]

Need to change this to include UWP: https://github.com/godotengine/godot/blob/b2d7641a0dd65a782f981fb1f73c5e84a90f816c/modules/mono/config.py#L85

[vnen]

Those I can't get around:

modules\mono\utils\mono_reg_utils.cpp(61): error C3861: 'RegOpenKeyExW': identifier not found
modules\mono\utils\mono_reg_utils.cpp(64): error C3861: 'RegOpenKeyExW': identifier not found
modules\mono\utils\mono_reg_utils.cpp(75): error C3861: 'RegQueryValueExW': identifier not found
modules\mono\utils\mono_reg_utils.cpp(81): error C3861: 'RegQueryValueExW': identifier not found
modules\mono\utils\mono_reg_utils.cpp(125): error C3861: 'RegCloseKey': identifier not found
modules\mono\utils\mono_reg_utils.cpp(147): error C3861: 'RegCloseKey': identifier not found
modules\mono\utils\mono_reg_utils.cpp(225): error C3861: 'RegCloseKey': identifier not found
inner_prod_aligned.c

It's not possible to access the registry on UWP.

[vnen]

Is it possible to use the .NET framework instead of Mono?

[NathanWarden]

@vnen That's how Unity does it, they use .Net (Core? I believe) for UWP, and then typically use Mono for everything else.

[vnen]

@NathanWarden I mean if Godot can already do it, if there's some build flag to enable it.

[NathanWarden]

@vnen That makes sense. I'm very sure you're on the right track, but I don't think that has been added. I haven't seen it yet at least. I can't imagine it would be too difficult though.

Were you thinking the build flag should just include .Net Core as an additional target (for use only with UWP), or to replace Mono entirely when built with that flag?

[vnen]

It should replace Mono. I don't see a reason to add Mono stuff to the binary and not use it.

[NathanWarden]

That makes a lot of sense, unless UWP builds are going to be available in Godot proper at some point. .Net Core is a very stripped down version of .Net and is incompatible with both Mono and .Net proper in a lot of places.

So, I suppose the idea is this would be a version that people just have to compile from source for now.

How Unity supports both is that they spit out the compile errors to the console for the incompatibilities at build time with .Net Core since their UWP template obviously uses it. It's a little bit annoying, but much better than limiting the API across the board. I think they build the .Net Core assembly against msbuild at export time. Thus, you can still just have one version of the editor, but the UWP build template is .Net Core only.

So, essentially, Unity builds the UWP template against .Net Core, but builds the editor against whichever .Net version they're using. Actually, they have multiple right now that you can select from.

Sorry if I've just made a rabbit trail out of this. I suppose all you're trying to do is just simply seeing if a Godot build can compile against UWP :)

[vnen]

Well, I'm the maintainer of the Godot UWP port (or at least I try to), but I'm not really willing to put much effort into the C# support. So if @neikeq can make it work with .NET I can help with the UWP part.

With UWP we can add the dependencies in the manifest which are installed automatically, so it probably doesn't need any additional library.

[NathanWarden]

I hear you, it would be quite a bit of effort. Plus, it doesn't have to all be perfect on the first pass either. Thanks for all of your hard work :)

[akien-mga]

Moving to 3.2 milestone, for 3.1 the focus is on getting the desktop platforms in good shape, plus maybe Android support if we can figure out the buildsystem.

[GeorgeS2019]

@vnen I am excited that there is interest on Godot for UWP.
I see lots of potential for Godot as an alternative to Unity for Hololens 2 that is running on Snapdragon 850.

I believe Hololens OS is a variant of the Windows 10 on ARM

I am interested to know if there is a community interest to
(1) Get Godot running native in Windows 10 on ARM, as a step to get Godot eventually running on Hololens 2
(2) raise Microsoft Hololens team to include Godot as one of the game engine

[GeorgeS2019]

I am closing these issues so we can focus on getting UWP to export consistently
Other related issue that is relevant

[neikeq]

This won't happen until at least June as it's not part of my current roadmap. It should not require much work to get this done as I suppose it will share most of the code from Windows, but I have zero experience with UWP.

[Calinou]

@GeorgeS2019 If anything, UWP seems to be getting less and less popular among Microsoft product users. Also, SDK project support is planned for Godot 4.0.

[GeorgeS2019]

Is this proposal to be included in 4.0 milestone?

[GeorgeS2019]

@akien-mga I understand you are busy. There is another important feedback 2 hours ago. Could you consider putting this PROPORSAL to 4.0?

[akien-mga]

No. Please let us manage our milestones as we see best fit. Commenting on all UWP-related issues to get them added to a milestone is not going to change our priorities.

[GeorgeS2019]

@akien-mga I definitely respect your decision.

The proposal has nothing to do with UWP, but the .NET standards 2.0 to 2.1 and SDK project which you seems to have arranged a higher priority for Milestone 4.0 BUT not yet officially assign to 4.0

[akien-mga]

Well then please don't cross-reference unrelated issues, this issue here is about C# support on UWP.
There are no milestones on the godot-proposals repository as of now.

[FeatherAntennae]

Microsoft's official plan is to deprecate .NET Framework and release ".NET 5" by the end of the year (planned for November), which is the next version of ".NET Core" and is supposed to be the only thing .NET going forward.

In theory it's supposed to kinda replace mono too.

It includes support for UWP of course, but it's also what Microsoft is pushing as the multiplatform .NET thing to use.

No idea of it's going to be any good, but it's definitely something to keep in mind if we're going to put a lot of effort to make C# work with UWP.

[FeatherAntennae]

@aurodev WinUI is also changing.

WinUI 3 is going to be independent of UWP and is supposed to support everything even Win32 directly.

[GeorgeS2019]

Exactly @FeatherAntennae this is why I proposed WinUI as one of Godot Export, an extension from UWP export

I have looked into how Godot is exporting UWP as UWP console. I believe it should not be too complicated to export as a UWP control too ( or WinUI ).

With that Godot is relevant to WinForm, WPF - the bulk of business in-house apps seeking for help how to modernize :-)

[GeorgeS2019]

However, the bigger next step for c# support in Godot 4.0 is (beyond UWP export but) to plan a path to leverage the opportunities presented by Microsoft .NET going towards .NET5. We need to discuss the various opportunities.

Some of the issues to address the godot 4.0 path towards .NET5 (Nov2020)

• Small project files (SDK-style) (do we need to test compiling c# export using both the Mono MSBuild and .NETCore dotnet build?)
• More choice on runtime experiences: mono versus CoreCLR (shall godot support both runtime experiences?)
• CoreFX will be extended to support static compilation of .NET (ahead-of-time – AOT), smaller footprints and support for more operating systems: Are we on track with that by adopting Mono 6.6 [another link1 and link2] instead of staying with mono 6.4

[Noemata]

Hopefully, the benefits of the UWP .Net Native compiler will not get lost in the mix. Some projects require perf and a much harder path to disassembly. The UWP .Net Native compiler is quite mature at this point. Its compiled code is not a open book. JIT only makes sense if you don't care about folks peering into your work since you are effectively releasing the source for modules that need to be jitted. Byte code obfuscation is both a drag on perf and stability.