Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Port game to .NET Core #20

Closed
ekolis opened this issue Sep 23, 2019 · 8 comments · Fixed by #96
Closed

Port game to .NET Core #20

ekolis opened this issue Sep 23, 2019 · 8 comments · Fixed by #96
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@ekolis
Copy link
Owner

ekolis commented Sep 23, 2019

I think this is necessary for porting to Xamarin #13 ? .NET Core 3.0 supports Windows Forms on Windows (not on Linux/Mac yet) so we should not have all that much to worry about, hopefully...

@ekolis ekolis added the enhancement New feature or request label Sep 23, 2019
@ekolis ekolis added this to the future milestone Sep 23, 2019
@ekolis ekolis added this to To do in core via automation Sep 23, 2019
@ekolis ekolis added this to To do in winforms-gui via automation Sep 23, 2019
@ekolis
Copy link
Owner Author

ekolis commented Sep 24, 2019

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/

@ekolis
Copy link
Owner Author

ekolis commented Apr 20, 2020

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

@KarbonKitty
Copy link
Contributor

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.

@ekolis
Copy link
Owner Author

ekolis commented Apr 25, 2020

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...

@KarbonKitty
Copy link
Contributor

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).

@ekolis ekolis linked a pull request Apr 28, 2020 that will close this issue
@ekolis ekolis changed the title Port game to .NET Core 3.0 Port game to .NET Core Apr 28, 2020
@ekolis ekolis modified the milestones: future, alpha-10 Apr 28, 2020
@ekolis ekolis moved this from To do to In progress in core Apr 29, 2020
@ekolis ekolis moved this from In progress to Review in progress in core Apr 29, 2020
@ekolis
Copy link
Owner Author

ekolis commented May 10, 2020

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

@KarbonKitty
Copy link
Contributor

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?

@ekolis
Copy link
Owner Author

ekolis commented May 10, 2020

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

core automation moved this from Review in progress to Done May 21, 2020
winforms-gui automation moved this from To do to Done May 21, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
core
  
Done
winforms-gui
  
Done
Development

Successfully merging a pull request may close this issue.

2 participants