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

Consider moving to .NET Core #1415

Open
nattthebear opened this issue Jan 3, 2019 · 4 comments
Open

Consider moving to .NET Core #1415

nattthebear opened this issue Jan 3, 2019 · 4 comments
Labels
Meta Relating to code organisation or to things that aren't code re: Multiplatform Relating to the Linux and macOS ports (Mono Framework, and eventually .NET Core)

Comments

@nattthebear
Copy link
Contributor

nattthebear commented Jan 3, 2019

.NET Core 3.0 now has WinForms. I think we should move BizHawk over.

Benefits:

  • Can deploy exactly the runtimes we want with our application, no more mucking around with prereq installers.
  • Can update to new versions of .NET Core without needing to worry about our users updating.
  • Can get some minor performance improvements right now - much has been improved compared to .NET Framework 4.8.

Drawbacks:

  • Fully self-contained builds will be much larger than current builds. We could also create a release that requires .NET Core to be installed on the target machine, which would lose most of the benefits from above but bring the size back down.

re: single-file, note API incompatibility (MSDN) and dotnet/runtime#42772

@Sappharad
Copy link
Contributor

As another benefit, I think this might be relevant to the post I made yesterday regarding the macOS port: http://tasvideos.org/forum/viewtopic.php?p=479475#479475

Specifically, I'm using an alternative 64-bit implementation of WinForms instead of the 32-bit one that ships with Mono and a custom fork of OpenTK with a modified GLControl to work against the 64-bit implementation. My fork has all of the System.Drawing & System.Windows.Forms references replaced with references to DLLs included with the code.

I suspect that switching to .NET Core 3 might make it easier for me to substitute the WinForms implementation without making invasive changes like I have now. I haven't thought about how yet, but it's probably going to be easier for me to substitute a nuget package than replacing a bunch of references everywhere. And I'm stuck with the bigger binary problem already since I migrated to the Xamarin stuff that will bundle mono into the mac builds.

@YoshiRulz YoshiRulz added the Meta Relating to code organisation or to things that aren't code label Feb 2, 2019
@YoshiRulz
Copy link
Member

YoshiRulz commented Jul 22, 2019

It goes without saying that I'm in favour of this (because it will work better on Linux and allows us to use C# 9.0 and above).


edit: There was a wall of text here, but it was outdated. See #2260 and #2261.

@YoshiRulz YoshiRulz added the re: Multiplatform Relating to the Linux and macOS ports (Mono Framework, and eventually .NET Core) label Jul 22, 2019
@YoshiRulz YoshiRulz added App: DiscoHawk Relating to DiscoHawk tool App: EmuHawk Relating to EmuHawk frontend labels Jul 22, 2019
@YoshiRulz YoshiRulz removed App: DiscoHawk Relating to DiscoHawk tool App: EmuHawk Relating to EmuHawk frontend labels Nov 4, 2019
@YoshiRulz
Copy link
Member

YoshiRulz commented Dec 10, 2020

Possibly breaking changes to WinForms:

  • net48 => netcoreapp3.1: MSDN
  • netcoreapp3.1 => net5.0: MSDN (first page, check sidebar under Breaking changes by area > Windows Forms)
  • net5.0 => net6.0: MSDN (ditto)

@YoshiRulz
Copy link
Member

YoshiRulz commented Jul 27, 2021

Just rebased hammer-and-duct-tape and got the diff looking good (+225/-18). As before, there's a new solution and new projects specifically for Linux, each project including all the source files of its counterpart but targeting net48. The idea being that the branch can be merged without disrupting Windows devs' workflows—I could have instead left the current projects on net48 and added new projects targeting net6.0. Either way, I need help with getting it on par w/ master so it can be merged ASAP.

edit 2021-12-04: .NET 6 now. In my brief testing, the UI was less responsive, and there was a framerate drop in managed cores (SMB1 title screen demo in NesHawk dropped 110 fps -> 100 fps). Unmanaged cores work (I tried Gambatte and Mupen64Plus), didn't try Waterbox. Direct3D and OpenGL both failed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Meta Relating to code organisation or to things that aren't code re: Multiplatform Relating to the Linux and macOS ports (Mono Framework, and eventually .NET Core)
Projects
None yet
Development

No branches or pull requests

3 participants