Upgrade Editor to .NET 6?

[edmundito]

Hello, not a feature request but a post to discuss and maybe come up with actionable things if we get anywhere. I was wondering if anyone has explored upgrading the editor from .NET 4.6 to .NET 6, and maybe list out the current challenges.

[ericoporto]

I think that is a too huge step. Currently first step is coming up with a docker image that can build everything on VS2019. See #1508 .

But I would prefer to keep at most in .NET 4.8 for as long as possible because it can run better on Wine - so on Linux and macOS through crossover. Unless someone can verify and prove that this .NET 6 runs Winforms on these nowadays - my previous experience on the older version was it didn't.

[ivan-mogilko]

This is a question of comparing pros and cons, what benefit will such move give to us, potentially? IMO frameworks should not be upgraded without a good reason, but this question does not mention any; could you elaborate why did you bring this up @edmundito ?

[edmundito]

To clarify, this is not a feature request. I wanted to ask wondering if anyone has tried this before and ran into problems. This issue can be used as searchable record of the challenges.

@ivan-mogilko if you'd like to know one reason I'm curious about this is to explore the multi platform capabilities of .NET introduced in more recent versions.

[ericoporto]

There are no new multiplatform capabilities. We use C++/CLI and Winforms, both MSVC and Windows exclusive.

[persn]

If you're going to upgrade that far you might as well go for NET8?

I've experimented with this before however

1. The Visual Studio minimum requirement needs to be lifted up as @ericoporto already mentions.
2. Then the csproj files needs to be upgraded to SDK format, which I actually already did in a branch years ago, not sure if I still have it
3. The Native proxy would need to be upgraded so that it's compiled with a C++ compiler that understands NET6 if it doesn't already
4. Then finally you'd need to compile the editor to NET6 and fix any issues that pops up

I don't think you're going to be able to explore any multiplatform capabilities though due to so much of the code base being reliant on the Native proxy which is Windows only. And also in NET5 and later, WinForms became a completely Windows only tech, I don't even think it has support through Mono. Unless we're going to write a completely new editor with a different framework or language it would be though

[edmundito]

@persn what led you to explore upgrading the .NET version?

I don't think you're going to be able to explore any multiplatform capabilities though due to so much of the code base being reliant on the Native proxy which is Windows only.

This is something I wasn't aware of!

And also in NET5 and later, WinForms became a completely Windows only tech, I don't even think it has support through Mono. Unless we're going to write a completely new editor with a different framework or language it would be though

What I've been trying to understand how much of the existing C# code can be leveraged to create a cross-platform editor. One option could be to leverage Mono, but I don't know the project's current status and whether it's being supported in the long term. Another option would be to explore .NET MAUI and create a new editor.

[ivan-mogilko]

The problem of the Native part in the Editor has been discussed many times in the past, here and on AGS forums.

For example, this is one of the older related tickets: #442

As of AGS 4, roughly following tasks are still done by a native C++ code:

• GUI preview
• Views preview (i think still?)
• Font preview
• Creating and reading spritefile (editor still uses native sprite cache, having to convert native bitmaps to managed ones for display)
• Game compilation (multiple steps, including a script compiler, room compiler, and maybe something else).

What I've been trying to understand how much of the existing C# code can be leveraged to create a cross-platform editor.

An approach, that was discussed before, and that may potentially let create another editor easier, is to separate number of tasks from the Editor into standalone tools. This refers to anything that creates project source files, and compiles final game files out of project source.

Standalone game compilation has recently been grouped in this ticket: #2316 But other tasks may be done separately.

[persn]

what led you to explore upgrading the .NET version?

I was exploring the possibility of running a server from the the AGS editor that allows communicating through a REST API. This would potentially allow anyone to develop a client plugin to their favorite IDE/text editor. The client can be on any computer as long as the server runs a windows machine, or with WINE.

I wasn't interested in doing this on .NET framework however, because learning ASP.NET isn't a skillset which future potential employers are looking for. This is actually counter intuitive because the advantage of running the editor as a server would be that it would work with the editor as is without any modification. So it should probably be a plugin instead of a new executable

It was just for fun and I didn't get very far. Any code that hit the native proxy would crash because I'm not able to update the C++ tools on my own.

What I've been trying to understand how much of the existing C# code can be leveraged to create a cross-platform editor. One option could be to leverage Mono, but I don't know the project's current status and whether it's being supported in the long term. Another option would be to explore .NET MAUI and create a new editor.

My impression is that development of Mono has pretty much stopped in favor of .NET 5+, but even if you tried doing Mono you'd need to get rid the native proxy because that still doesn't work outside of Windows.

Making a new editor from scratch and avoid using any "exists on one OS only" solutions along the way is probably the most realistic way this is going to happen based on how the code base looks right now at this very moment. It would still be an advantage to get rid of chunks of the native proxy however, in AGS4 we have already removed most or all of the parts of the native proxy that is responsible for loading the .crm room files.

In fact when comparing master and ags4 branch, NativeProxy.cs has been shrinking a lot in AGS4 👍

The response to MAUI has been that it's pretty terrible in general, and it's not a good choice for cross platform UI because Microsoft has decided that Linux is a server OS only so they will not develop any GUI frameworks for .NET Linux. The best bet for developing a modern cross platform UI on .NET at this moment right now is AvaloniaUI

[ValorZard]

I second using AvaloniaUI for AGS. Stride Engine is actually switching to Avalonia as well: https://github.com/stride3d/stride/issues/1629