Port game to .NET Core about freee HOT 8 CLOSED

Plus there are a ton of performance improvements in .NET Core which could not be applied to .NET Framework: https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-core-3-0/

from freee.

.NET Core 3.1 is out, at least in preview. And .NET 5 is coming in November...

from freee.

So I've run a .NET Portability Analyzer on the FrEee, and it seems that moving to .NET Core should be rather simple - at least assuming we are happy with .NET Core 3.1.

Both FrEee ("core") and FrEee.WinForms show no incompatibilities when run against .NET Core 3.1. .NET Standard seems to lack some of the APIs necessary, but I assume that there is no need to distribute it as a stand-alone class library, so it should be good to just compile it again .NET Core (.NET Standad has no System.Drawing, for example).

There are some problems in the test code, and those come from two sources:

1. There were some changes in the unit test framework, which should be trivial to fix or replace (some attributes were renamed, and I think the same go for asserts).
2. AppDomain creation and management; those are a bit more problematic, since pretty much entire AppDomain was dropped from .NET Core with no plans to add it back, as far as I know. From reading the test, I couldn't tell what is actually being done with it (especially as the other two projects aren't reported as using those methods), so I don't know how viable is it to stop using those methods?

In particular, there is AppDoman.CreateDomain method and AppDomainManager class that are used, but unavailable in the .NET Core.

from freee.

Great! Last time I checked compatibility with .NET Core, it wasn't quite so good. But if 3.1 adds the APIs we need then I'm all for converting. Odd that .NET Standard would not include System.Drawing if both Core and Framework do...

As for AppDomains, I am using them to sandbox the scripts so a malicious script can't harm a player's system. However I've heard that that's not so reliable, so I'm not against removing them anymore; they would only serve to slow down the game if that's the case. Players will just have to trust mod authors I guess, to make sure that mod scripts don't contain malicious code...

from freee.

System.Drawing is a platform-specific extension (Windows-only), so it's not included in .NET Standard (which is also a bit outdated, as it seems that .NET 5 will mostly obsolete it...), at least from what I can tell.

I will try to research running code-enabled mods in a relatively safe environment, but it seems that it's far from trivial, and AppDomains even have a big red note from MS that they aren't really all that sandboxy (see here: https://docs.microsoft.com/en-us/dotnet/framework/misc/how-to-run-partially-trusted-code-in-a-sandbox).

from freee.

I just discovered that .NET Core WinForms app will not run in Mono on Linux; we might want to reconsider this...

from freee.

Well, for multiplatform GUI some third party solution is more or less required when talking about .NET. Should we move this discussion to #13 ? Or maybe a new issue would be better, to generally select a GUI framework to use?

from freee.

Yeah, a new issue would be good. Let me create one... OK, see #101 !

from freee.