C# status and plans towards 3.1

[neikeq]

I'm opening this issue to inform other developers interested in the mono module about the current status and the plans towards 3.1.

As you may have notice, I've been quite inactive during the last month and a half. This is related to my studies, and there is nothing that can be done about it. This low activity will sadly continue until June 14, approximately, when I will finally be free once and for all to focus entirely on Godot.

Since I will have very little time to dedicate to Godot during this period of time, I decided to make a list of essential tasks that need to done for the 3.1 milestone, and postpone everything else for future releases. The list is the following:

• Finish the C# API. This means that any changes that break compatibility will have to be done, in principle, before 3.1beta. The most important part of the API that is missing are the Dictionary, Array and Pool*Array wrapper classes. Status: Dictionary and Array are done, but there are no Packed*Array wrapper classes yet.
• Finish project exporting. This is almost done. It's just missing exporting the right mono runtime library for the target platform, making it work with the Export PCK/Zip(-only) option, and more testing of course.
• Upgrade GodotSharpTools to reference the Microsoft.Build nuget packages (these are Windows-only, need to build msbuild from source) instead of Mono's Microsoft.Build assemblies, and bundle with the Roslyn compilers. This way we can provide a working build environment on all platforms. It will increase the editor size, but I consider it to be necessary.
• Bundle all the assemblies that can break compatibility between versions of mono (because of internal calls), not only mscorlib as we are doing right now. Godot shouldn't require Mono 5.4 to be the installed version.
• Bug fixing. Although last in the list, this is the main focus.

Other developers are free to make contributions to any area. However, keep in mind that I may leave them aside for review after 3.1 is released if I don't consider them essential for this release. Please, let me know if you think I'm forgetting something in the list above.

I'm keeping this issue open for discussion.

[neikeq]

Finish project exporting. This is almost done. It's just missing exporting the right mono runtime library for the target platform, making it work with the Export PCK/Zip(-only) option, and more testing of course.

Just to clarify, it's already possible to test project exporting. All you need is to compile the export templates and place them in $HOME/.local/share/godot/templates/3.1.dev.mono/ (%APPDATA%/Godot/templates/3.1.dev.mono/ on Windows). You will have to copy the mono runtime library manually as mentioned above. Keep in mind only desktop platforms are supported for now.

[KellyThomas]

Long term which platforms can we expect to support mono exports?

[PJB3005]

I believe that eventually the plan is to support ALL platforms, even web (MSIL -> wasm is something that mono and such are working on).

With the GodotSharpTools bit & build: don't you mean GodotSharpEditor? I thought that was the one that needed it to build the csproj files and such.

[neikeq]

Platforms:

Desktop: Right now, we support the x11, Windows and OSX platforms. I didn't test on Server, UWP and *BSD yet, but they may be working already. Mono does not fully support Haiku yet.
Mobile: We will support both Android and iOS. The Android port should be straightforward. iOS exporting will require the extra step of compiling the assemblies ahead of time.
WebAssembly: There is work to bring the Mono runtime to WebAssembly, so this should be possible in the future. I'm not sure if embedders can test it at its current state.
Consoles: No idea. All I know is there are ports provided by third parties.

With the GodotSharpTools bit & build: don't you mean GodotSharpEditor? I thought that was the one that needed it to build the csproj files and such.

GodotSharpTools is the one that the editor uses for reading/editing with csproj files, building solutions and executing MonoDevelop.
GodotSharp and GodotSharpEditor are the API assemblies. I will rename them to GodotAPI and GodotEditorAPI respectively before 3.1 to avoid confusion.

[PJB3005]

For what it's worth, I can definitely tell you that Server loads up successfully for the purposes of exporting to Windows. Haven't tried to run actual code on it though.

…

On Mon, Apr 23, 2018, 10:47 Ignacio Etcheverry ***@***.***> wrote: Platforms: *Desktop:* Right now, we support the x11, Windows and OSX platforms. I didn't test on Server, UWP, *BSD and Haiku yet, but they may be working already. *Mobile:* We will support both Android and iOS. The Android port should be straightforward. iOS exporting will require the extra step of compiling the assemblies ahead of time. *WebAssembly:* There is work to bring the Mono runtime to WebAssembly, so this should be possible in the future. I'm not sure if embedders can test it at its current state. *Consoles:* No idea. All I know is there are ports provided by third parties. With the GodotSharpTools bit & build: don't you mean GodotSharpEditor? I thought that was the one that needed it to build the csproj files and such. GodotSharpTools is the one that the editor uses for reading/editing with csproj files, building solutions and executing MonoDevelop. GodotSharp and GodotSharpEditor are the API assemblies. I will rename them to GodotAPI and GodotEditorAPI respectively before 3.1 to avoid confusion. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18364 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHu1w6os8QgftKsVEE3aMDufzeSygNMaks5trZUWgaJpZM4Te_7X> .

[DevMagicLord]

I'm interest a lot in C#.
Mainly because Object Oriented language and because game source code is obfuscated when the game is published unlike GDscript.

[LaurentOngaro]

thanks for this info.
Is the following compatibility bug planned for the next devs ?
Running a C# project with a 32 bits binary on a 64 bits windows causes a crash
I think It's important because , if I'm right, only 64 bit versions with mono can be used and exported till now.

[aaronfranke]

Shall we turn this post into a [Tracker] with a list of to-do items via - [ ]?

[DevMagicLord]

Instead of to-do create new individual issues for each item.

[raymoo]

@DevMagicLord Isn't GDScript compiled to bytecode before packaging?

[so-rose]

Just to clarify, it's already possible to test project exporting. All you need is to compile the export templates and place them in $HOME/.local/share/godot/templates/3.1.dev.mono/ (%APPDATA%/Godot/templates/3.1.dev.mono/ on Windows). You will have to copy the mono runtime library manually as mentioned above. Keep in mind only desktop platforms are supported for now.

So, I tried to do exactly this. It didn't work! I thought I'd report my findings for the record - perhaps it can be of some use for you later @neikeq!

My commands were (from a totally clean repository clone at 1113a73):

# Build Godot to Generate Glue
scons p=x11 tools=yes module_mono_enabled=yes mono_glue=no -j 32
bin/godot.x11.tools.64.mono --generate-mono-glue modules/mono/glue

# Build Godot w/Mono
scons p=x11 target=release_debug tools=yes module_mono_enabled=yes -j 32

# Generate Export Templates
scons p=x11 target=debug tools=no module_mono_enabled=yes -j 32
scons p=x11 target=release tools=no module_mono_enabled=yes -j 32

I then copied the export templates to $HOME/.local/share/godot/templates/3.1.dev.mono/ as described, and renamed them to match the distributed export templates.

I proceeded to open the built editor, godot.x11.opt.tools.64.mono, with a test project (which contains no C# code whatsoever - it's entirely GDscript; there isn't even a .csproj file) and export a Linux/X11 Build to res://bin/. I then copied the following files to the same folder as the export:

• GodotSharpTools.dll
• libmonosgen-2.0.so
• mscorlib.dll

When I ran the exported project, this happened:

$ ./test.x86_64 
Mono: Initializing module...
ERROR: _initialize_and_check_api_hashes: Mono: Core API hash mismatch!
   At: modules/mono/mono_gd/gd_mono.cpp:318.
Mono: Runtime initialized
Mono: INITIALIZED
<Black Screen>
^C

There's the error! It is, in fact, the error described in #14584 .

My mono version is 5.10 - not sure if that matters:

Mono JIT compiler version 5.10.1.20 (tarball Thu Mar 29 10:48:35 UTC 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           __thread
	SIGSEGV:       altstack
	Notifications: epoll
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug 
	Interpreter:   yes
	LLVM:          supported, not enabled.
	GC:            sgen (concurrent by default)

[Zireael07]

My mono version is 5.10 - not sure if that matters:

Yes it matters, Godot supports only 5.4.

[paulloz]

My mono version is 5.10 - not sure if that matters:

Yes it matters, Godot supports only 5.4.

That is only true when you're using the released binaries. When you're compiling yourself you can pretty much use any recent Mono version.

[PJB3005]

@so-rose I believe that is the issue to be fixed by #18514

[neikeq]

Yes, that issue is fixed by #18514. Although it shouldn't prevent your game from working, it's just a false warning.

You don't need to copy GodotSharpTools.dll and mscorlib.dll with the exported game. GodotSharpTools is editor only, and the editor already copies mscorlib (inside the PCK file).
libmonosgen-2.0.so is not needed when static linking mono. You can do that with mono_static=yes when building.

Export PCK/ZIP works with Mono now, so the only thing missing is copying the mono shared libraries (if they were linked dynamically), and project exporting will be done.

[mhilbrunner]

From #19101:

Things that I'd expect before I'd consider C# production ready, in order of importance:

• Crashes (there are ~25 known ones currently)
• Exporting (Implement Mono/C# project exporting #15615)
• API should be mostly final. There is still some discussion that doesn't appear resolved? (Remove underscores in front of C# "lifecycle" methods to match the language's conventions #14466)
• Editing, renaming, (re)moving files should be supported; there should be no need to hand-edit generated project files (Renaming a .cs file does not edit the .csproj file #12917, Mono: Building project solution doesn't detect that .cs scripts were deleted #12415, Mono: dependency classes aren't added to solution automatically #11930)
• Debugging should work (Cannot get visual studio code to debug mono #13837, Stack traces inside Mono do not show file/line numbers. #14822)
• We should have at least one minor version (so 3.1) with working exporting for C# supported before we can declare the exporter production ready

To explain the last point:

IMO, we need to test C# more widely before calling it production ready. I propose to release 3.1 (or 3.0.3) with working exporting and wait for some (to be determined) time after that, seeing what issues crop up, before calling it that.

Because if I was one of the first users to run into export issues because thats a new functionality, and C# as a whole was called production ready, I'd be upset. Opinions?

[neikeq]

That's what beta is for, isn't it?

[aaronfranke]

Would anyone be opposed to renaming Fposmod() in Mathf to Mod()?

1. None of the other float-returning methods start with the letter F

2. It's not PascalCase if you count pos and mod as words

3. The pos distinction is not necessary because for "non-positive modulus" also known as "remainder" there's already an operator in C# called %. People using the Mathf function would only ever be looking for something that wasn't in the C# language.

4. Mod() looks a lot cleaner than Fposmod().

As someone who uses this function a lot in my code, I would definitely appreciate this change.

EDIT: #19231

[paulloz]

I hate to be the person bringing back the same thing over again but I think the generic GetNode (#16871) is still something that'd be good to address before being production ready (it can be seen as part of the «API should be mostly final» part).

[PJB3005]

#18773 is something that I feel also needs doing before we can mark C# as stable.

[mhilbrunner]

Also, not only writing those new docs but maintaining them.

[neikeq]

The class reference description for the generated API is automatically generated from the existing class reference. It's still not translating it from bbcode to xml tags, but that can be easily solved. A problem would be translating the GDScript code examples (inside code tags) in the generated bindings to C#, if we desire to do so.
I don't see any problem in maintaining docs for the part of the API we write manually.

[aaronfranke]

Should Printerr be changed to PrintErr? Currently kinda looks like "Printer".

EDIT: #20337

[akien-mga]

I've opened some issues to discuss Mono/C# support for the remaining platforms:

• Mono/C# support on Android #20267 for Android
• Mono/C# support on iOS #20268 for iOS
• Mono/C# support for HTML5 #20270 for HTML5
• Mono/C# support for UWP #20271 for UWP

[Nufflee]

I'm working on #12917 and #12415.

[neikeq]

@Nufflee Good luck. You may get stuck due to #10946 though. At least that's what happened to me last time I tried.

[Nufflee]

@neikeq Hmm, I'm not too sure how that's really related to this but we should probably continue this conversation in the PR.

[aaronfranke]

Another minor issue, I noticed that the Vector Lerp method in Godot is called "LinearInterpolate" rather than the shorter and probably more familiar "Lerp". More familiar to users, since it's called Lerp in Unity. The name "LinearInterpolate" is also inconsistent with the other method "Slerp" which isn't expanded to "SphericalLinearInterpolate". And most importantly, this is inconsistent with the Mathf.Lerp method.

Would anyone be opposed to changing "LinearInterpolate" to "Lerp"? I would also have to change the C++ code to "lerp" in order to be consistent, or I can just change the C# code if that's desired.

EDIT: #20371 (no C++ changes, for now, as per Nathan's suggestion)

[NathanWarden]

I think your suggestion would make the Godot API itself more consistent since the default floating point math function is also called lerp. I wouldn't be opposed to it being Lerp in C#, and at some point it would make sense for the C++ side to also be called lerp. I'm not opposed at all to changing the C++/GDScript side now, but I think API breakages may not be wanted in the 3.x series. I guess it can't hurt to just make a PR explaining the issue.

[exts]

@NathanWarden I believe since c# is unstable breakage should be allowed with 3.1

[savuori]

Should Sync Script Changes work with .cs files as well? Live updating code would be super handy for exploratory development and fine-tuning.

[immccc]

Maybe a bit offtopic, but as the code of my game is constantly growing, and I prefer C#/Mono for a list of reasons, but haven't used it so far because its non fnished status, perhaps a good idea would be to have a GDScript to C# converter, so that there is a basis that will make refactoring code to C# easier.

[aaronfranke]

@immccc You are welcome to develop that feature, but I don't think that would be very easy to do, and it would always be imperfect. If you want to switch your code to C# it's best to do it manually.

[immccc]

@aaronfranke that would be imperfect for sure and the user will have to review and tune each source file, but the amount of tedious work writing file per file as a middle age scribe monk is saved, at least a considerable part :) (or that's the idea)

[robgraeber]

For those wondering how you’d even approach a gdscript converter, there was a guy a few years ago who made a Obj-C to C# converter. The way he did it was first convert it to TXL, which is an intermediary language made for this thing, then convert it to C#. http://razum.si/automagical/about

…

On Sat, Aug 25, 2018 at 1:15 AM immccc ***@***.***> wrote: @aaronfranke <https://github.com/aaronfranke> that would be imperfect for sure and the user will have to review and tune each source file, but the amount of tedious work writing file per file as a middle age scribe monk is saved, at least a considerable part :) (or that's the idea) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#18364 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACRvBzJ4xG-aRijv4Vy5h523AJm3YBSmks5uUQe0gaJpZM4Te_7X> .

[aaronfranke]

Should Cartesian2Polar and Polar2Cartesian be in Vector2 instead of Mathf?

[swarnimarun]

@aaronfranke I say Vector2 makes more sense. As even a polar vector is a vector.

[Byteron]

I hope this is the right issue for that:
I was wondering if it would be possible to rename Classes that already exist in C#, like e.g. Godot.Dictionary to Godot.GDictionary. I had a couple of conflicts because of these having the same name.

[aaronfranke]

@Byteron This has already been fixed, but it hasn't arrived in a release version yet. In 3.1 and possibly 3.0.7, Godot.Dictionary will be moved to Godot.Collections.Dictionary.

[Zireael07]

How soon is the bundled Mono coming?

[Byteron]

@aaronfranke only for Dictionary, or for all shadowing classes?
And thank you for the quick answer! :)

[neikeq]

Only Dictionary and Array for now. Are there any others that cause problems? For one, I know Thread. I would like to move it to Godot.Threading together with other related classes like Mutex and Semaphore.

[Byteron]

There also is Godot.Directory and System.IO.Directory.

[NathanWarden]

Similar to @Byteron, I had System.IO.File and Godot.File conflict a day or two ago and it took me a minute to figure out what was going on. Can we put those both under Godot.IO to mirror the System namespace? I'd be happy to make this change if it's wanted. :) I could take a look and see if there is any other IO related code we could tuck in there too.

[exts]

Issues I think should make 3.1:

• Is C# support broken on the 32-bit versions? #20012
• GD.Print() prints 'Null' with non-Godot type objects. #18969 (redirect mono's print and printerr to the editor output dock)
• Expose signals and callbacks as C# events #15558
• Godot ignores namespace information when instantiating C# classes #17409 (neikeq said he already had the solution for this, just needed to add it)
• MoveAndSlide / IsOnFloor and MoveAndCollide don't work in C# scripts #19898 (api issue that should work the same as it does in gdscript)
• Mono: Building project solution doesn't detect that .cs scripts were deleted #12415

[neikeq]

1. is mostly done. It's something that will be constantly evolving. More changes will be made in 3.2. And important changes may have to wait for 4.0 to avoid badly breaking compat.
2. is done. Exporting should work now for desktop platforms.
3. will take some work since we need to build msbuild from source and figure out how to bundle it with the editor, so I'm pushing it to the next milestone.
4. is done. We bundle the mono bcl with the editor so the user doesn't need to install a specific Mono version.
5. is all that's left and can be tracker here: https://github.com/godotengine/godot/issues?q=is%3Aopen+is%3Aissue+label%3Atopic%3Amono+milestone%3A3.1

I'm closing this issue.