Migrate to .NET Core

[neilenns]

How to: https://docs.microsoft.com/en-us/dotnet/desktop/wpf/migration/convert-project-from-net-framework?view=netdesktop-5.0

Advantages:

• Can use GitHub actions to compile the project and verify there are no build errors on every pull request
• Can use VSCode for development (?)

I have no idea how much work this is or whether it's even possible. Logging this so I don't forget about it and can spend some time exploring to see if it's even possible.

[neilenns]

I gave this a first attempt this morning. I got the project migrated to .NET 5.0 and it would build, but when running it kept complaining that the SimConnect DLL was in an "incorrect format". I confirmed both the Microsoft.FlightSimulator.SimConnect.dll and SimConnect.dll files were in the same output folder but that didn't fix it. Did some searching, found other people with the same general problem, but none of the suggested fixes worked.

Decided to set it aside for a while and will come back to it later.

Note that if you switch to a branch with the .NET 5.0 changes then back to the main 4.5.2 branch you will get build errors saying the target framework isn't specified. No amount of resetting your branch will fix it. The solution is to delete project.assets.json from the obj folder as described here: https://yomotherboard.com/your-project-does-not-reference-netframeworkversionv4-8-error/

[neilenns]

For a second attempt I think starting fresh and doing an initial upgrade with https://docs.microsoft.com/en-us/dotnet/core/porting/upgrade-assistant-overview would be a good way to go. My first attempt used a different upgrade tool that focused simply on converting the project file format and that broke a ton of project configuration stuff (missed migrating x86, defines, etc.)

[neilenns]

It also requires thought to remove some of the folders in the project that probably shouldn't be checked in. E.g. all the CmdMessenger examples get built and result in duplicate output assembly errors, since the new project format automatically includes all files in the solution by default.

There are also multiple copies of Microsoft.FlightSimulator.SimConnect.dll checked in to various projects in the solution, that should probably consolidate to one location.

Also the post-build steps to manually copy files should likely be replaced with project-level settings on the file to say "Copy Local" and "If Newer".

[neilenns]

I wonder if it's possible to build a NuGet package for the MSFS SimConnect DLL?

[neilenns]

With regards to the framework error it appears SimConnect.dll is an x64 library. So why does MobiFlight build as x86? How did this ever work? Hmm.

From the CTrue.FsConnect nuget package:

"FsConnect uses the Microsoft.FlightSimulator.SimConnect .NET Framework library and the underlying native x64 simconnect.dll library. These files are distributed via the Flight Simulator 2020 SDK, currently version 0.10.0, but are included for easy use."

[neilenns]

Someone who seems to have gotten SimConnect working with .NET Core: https://github.com/bertrandpsi/CoreSimconnect

[kkr0kk]

Like he say --> 64 bits i'm not sure doc would stop 32 bits support.

[MobiFlight-Admin]

32 bit was necessary to work with FSX and Arcaze Boards, i used an old fsx simconnect.dll

[neilenns]

Might be time to think about a clean break release where mobiflight moves to Net core, and older sims need to use the older version of MF with only critical bug fixing taking place.

[MobiFlight-Admin]

I am looking into WinUI3 and electron.net - it is time for an overhaul for sure.