Document missing C# web export templates due to lack of upstream support

[Kezzo]

Godot version

v4.0.beta10.mono.official [d0398f6]

System information

macOS Monterey 12.5.1 (21G83)

Issue description

In a fresh project created with v4.0beta10 and export templates downloaded and installed, the web export templates files are missing at the expected path. This makes it impossible to create web builds afaik.

Steps to reproduce

1. Create new godot project with v4.0beta10
2. Create web export preset
3. Download export templates
4. Click on open folder in the export template download window
5. Observe that the required files for web exports are missing

Minimal reproduction project

N/A

[Calinou]

There are no C# export templates for HTML5 yet due to missing upstream support in .NET 6 (.NET 7 didn't address this).

That said, there are significant issues with the HTML5 export in 4.0, such as #68647 and #70691. I would recommend using 3.x if targeting HTML5 for now, regardless of whether you're using C# or not.

[Delpire]

What is the missing upstream support from .NET we're waiting on to get HTML5 support? Can we link that item here and then in whatever documentation gets created?

Not having HTML5 support for Godot 4 is preventing me from using Godot 4 when participating in game jams as I prefer uploading web builds.

[poke1024]

Since several people now independently wrote this same bug report, and the situation is as it is with Godot 4 stable, maybe it might make sense to mention Web export for Godot 4/Mono as "unsupported for now" somewhere central in the Godot mono docs.

[Sythelux]

There are no C# export templates for HTML5 yet due to missing upstream support in .NET 6 (.NET 7 didn't address this).

That said, there are significant issues with the HTML5 export in 4.0, such as #68647 and #70691. I would recommend using 3.x if targeting HTML5 for now, regardless of whether you're using C# or not.

I propose we make a Tracker ticket to collect things: why C# Support is missing, what can be done about it (split in: what can we do about it. What can dotnet devs do about it) and what can be done to make it verbose to the user. I also recently stumbled upon it just missing and I also consider it an important feature.

I saw here, on other tickets and on the release notes of 4.0 that there was supposedly a communication between core godot-devs about it, but there isn't really a transparent Ticket for us.

[ashelleyPurdue]

There are no C# export templates for HTML5 yet due to missing upstream support in .NET 6 (.NET 7 didn't address this).

What upstream support is missing, exactly? Is it something that we could expect in, say, the next year?
I'm trying to gauge whether or not I should use Godot 4 for a new project, in the hopes that web support comes while I'm still working on it.

[Calinou]

What upstream support is missing, exactly? Is it something that we could expect in, say, the next year?

We can't give an ETA as we don't know when contributors will be available to do the required work on both the .NET and Godot side. I wouldn't expect it to be ready for this year though, especially if you want to use a stable version and not a pre-release. If you need to use C# to target the Web platform right now, stick to Godot 3.x.

[Sythelux]

We can't give an ETA as we don't know when contributors will be available to do the required work on both the .NET and Godot side.

Is there a group of participants I could connect to? I'd like to help working on that.

[Zireael07]

@Sythelux Try Godot contributors chat at https://chat.godotengine.org/channel/navigation

[raulsntos]

I'd like to clarify the issue with supporting mobile and web platforms a bit since it seems that many users have been asking about it and feel like we've been very vague with our responses.

First of all, I'm not very familiar with these platforms so don't take what I'm about to say at face value. This is just my understanding of the issue and may contain inaccuracies. We are still evaluating which options are available as upstream progresses, and will post a clearer plan once we have it.

As far as I know, upstream support is referring to .NET not supporting building libraries for these platforms.

This may be confusing to some users since clearly you can already build .NET apps for mobile and web using Blazor and MAUI. The difference between those supported scenarios and Godot is that those are all applications and Godot C# projects are libraries.

To clarify, applications (where C# is the entry point) seem to be supported by upstream but libraries (where C++ is the entry point) are NOT supported (this is Godot's case).

Building C# libraries for these platforms may be supported in .NET 8.0. However, since this version of .NET is currently not released we can't know for sure that it will make it.

• The relevant issue to track this seems to be: [mono] Add support for library mode in the aot compiler dotnet/runtime#79377.

Assuming this feature is available in .NET 8.0 when it's released (November 2023), that means we can't guarantee Godot will support these platforms until at least next year (Godot 4.3 at the earliest).

Alternatively, since .NET already seems to support these platforms as long as C# is the entry point, it may be possible to support this in Godot by making Godot a library and the C# project the entry point.

• Related proposal: Add a build-time option to compile Godot as a shared library (for use in other languages) godot-proposals#6267.
• Related PR: LibGodot with GDExtension #72883.

Making C# the entry point is something that I would like to support. However, as you might imagine this requires Core support which means it doesn't depend just on the .NET team. Merging features that touch Core tends to be slow because it's a very critical area.

Having said all that, keep in mind that even if upstream gains support for this or even if using Godot as a library was implemented, it doesn't mean that C# will immediately gain support for these platforms. Further work may be required to fully support them from Godot C#'s side.

[reduz]

@raulsntos The main issue with this is that, on Android and WebAssembly, making C# the entry point and Godot a library is likely not going to work due to how these platforms work.
WebAssembly itself is still quite broken in this regard and on Android Godot is already a library that Android needs to open from Java.

So ultimately I am afraid the most we can do is wait until this feature is implemented and hope we can get it running after they add the experimental support.

[raulsntos]

@reduz Can you clarify why you think this won't work? It seems like LibGodot already supports this. The PR claims:

LibGodot allows the use of different C# runtimes allowing dotnetAOT compilation, C# android support, and C# web support.

There's a LibGodotSharp project that seems to be using it specifically with C#, I haven't tried it though. Maybe @Faolan-Rad can clarify if this is all working already or if I'm misunderstanding how this works.

[Faolan-Rad]

LibGodotSharp currently doesn't support the web but it could with a bit of work

[dannflor]

Building C# libraries for these platforms may be supported in .NET 8.0. However, since this version of .NET is currently not released we can't know for sure that it will make it.
The relevant issue to track this seems to be: dotnet/runtime#79377.

@raulsntos The relevant issue is now closed as completed (yay!). But at the end of the thread they caution against using libraries that contain iOS/Android bindings. Wouldn't Godot need to have those bindings to properly handle input events?

[kksgandhi]

Curious if — with the issue closed as the previous comment mentioned — it's just a matter of time until C# web export works, or if there are still unknowns that make the timeline indefinite?

[nathonNot]

I'm trying to make a game on the web side using godot 4. When I tried to publish a web demo to test, I found this problem. Now that .net8 has been released, it seems that the problems encountered under this issue have been solved, is there any way I can use godot4 to package the web?

[Calinou]

I'm trying to make a game on the web side using godot 4. When I tried to publish a web demo to test, I found this problem. Now that .net8 has been released, it seems that the problems encountered under this issue have been solved, is there any way I can use godot4 to package the web?

Not yet, as there are still a lot of changes that need to be made in Godot for that to be possible (even if we upgraded to .NET 8). It's not something we expect to be done for 4.2, given how complex it is to get right.

[Anutrix]

Can we have table of some kind in the docs that lists down what export platforms are supported by what Godot version(both by 3vs4v4.1vs4.2 as well as dotnet 6v7v8)?

[Calinou]

Can we have table of some kind in the docs that lists down what export platforms are supported by what Godot version(both by 3vs4v4.1vs4.2 as well as dotnet 6v7v8)?

For C# export, this is how it goes as I understand it:

OS	3.x	4.0-4.1	4.2
Windows	✅	✅	✅
macOS	✅	✅	✅
Linux	✅	✅	✅
Android	✅	❌	✅1
iOS	✅	❌	✅2
Web	✅	❌	❌
UWP	❌	N/A3	N/A3

Footnotes

1. Requires .NET 7 or later. ↩

2. Requires .NET 8 or later. ↩

3. Godot 4.0 and later doesn't support UWP. ↩ ↩²

[gaffe-buck]

I don't have the time or knowledge to work on this feature, is there perhaps a bounty I could contribute to? The lack of a C# web export feature specifically is an obstacle to adoption, particularly for game jammers.

[lewiji]

dotnet/runtime#94351

Am I right in thinking this is now the relevant tracker on the dotnet runtime for upstream support? Are there specific things on this list not yet supported that Godot requires? Reference types, GC, and threads stick out to me as things that Godot will probably need for .NET wasm exports, but I know basically nothing about this area, just curious.

[raulsntos]

Sorry for the late response, I'll try to respond to some unanswered questions in the thread.

The relevant issue is now closed as completed (yay!). But at the end of the thread they caution against using libraries that contain iOS/Android bindings. Wouldn't Godot need to have those bindings to properly handle input events?

@dannflor In Godot 4.2, the current Android support uses the linux-bionic runtime, this is a linux runtime that uses Android C (so basically Android without the JNI). And the iOS support uses NativeAOT which, as mentioned in the linked issue, seems to have the same limitations. This means that Android/iOS bindings will indeed not be available and will likely crash the game.

But this only refers to consuming the Android/iOS APIs from C# (the BCL), as long as you are using Godot bindings you should be fine because that goes through the Godot C++ code. It's not always a viable alternative though (e.g.: if you are consuming a C# library that you have no control over) but at least now you know what to expect.

This is one of the reasons why the current mobile platform support is currently considered experimental, it's still a work in progress.

Curious if — with the issue closed as the previous comment mentioned — it's just a matter of time until C# web export works, or if there are still unknowns that make the timeline indefinite?

@kksgandhi Web support likely depends on upstream, .NET currently doesn't allow building as a WASM sidemodule. There's an open issue that seems related in the 9.0 milestone (although keep in mind that doesn't mean it will be done in time for .NET 9.0):

• Blazor wasm dynamic linking native sidemodules dotnet/runtime#75257

There are also other alternative options we could explore.

dotnet/runtime#94351 Am I right in thinking this is now the relevant tracker on the dotnet runtime for upstream support? Are there specific things on this list not yet supported that Godot requires? Reference types, GC, and threads stick out to me as things that Godot will probably need for .NET wasm exports

@lewiji That issue tracks WebAssembly proposals and their adoption in the .NET WASM modules implementation, as I understand it they don't have to adopt those proposals but if they do they could take advantage of certain capabilities provided by the browser.

For example, the GC proposal is meant to allow WASM modules to use a GC provided by the browser so that the WASM modules themselves don't have to include their own GC implementation, that means the WASM module can be smaller and maybe faster in some cases.

So I don't think that issue is a blocker for us.

[Spycemyster]

There are also other alternative options we could explore.

@raulsntos There doesn't seem to be any progress made on the linked issue yet. I'm curious, in the case that WASM modules aren't supported after .NET 9.0, what are potential alternative options we can explore for getting web exports to .NET?

I don't have the time or knowledge to work on this feature, is there perhaps a bounty I could contribute to? The lack of a C# web export feature specifically is an obstacle to adoption, particularly for game jammers.

How would we go about proposing a bug/feature bounty for this?

[weebs]

As far as I can tell, I think the PR to make Godot a library and the new C# bindings based on the GDExtension APIs from @raulsntos should make it possible to embed Godot into a Blazor app with efficient FFI. Blazor is able to statically link with native libraries with AOT compilation using emscripten

https://learn.microsoft.com/en-us/aspnet/core/blazor/webassembly-native-dependencies?view=aspnetcore-8.0

[kpietraszko]

Just a note: the linked issue about dynamic linking native submodules has been moved from .NET 9 milestone to "Future"