Multi-target .NET Framework 4.8 and .NET 8 #3745
Conversation
| <PropertyGroup> | ||
| <UseWindowsForms>true</UseWindowsForms> | ||
| <EnableWindowsTargeting>true</EnableWindowsTargeting> | ||
| </PropertyGroup> |
There was a problem hiding this comment.
This will break compilation on Linux, you'll need to do it conditionally
There was a problem hiding this comment.
I've specifically set EnableWindowsTargeting to fix compilation on linux. What compilation problems are you seeing? It compiles fine for me.
There was a problem hiding this comment.
I haven't tried. I recall from last time I messed with hammer-and-duct-tape that <UseWindowsForms/> didn't work w/ the net48 TFM, and multi-targeting net6.0-windows prevented building on Linux—<EnableWindowsTargeting/> has obviously been added to fix that, but does it also fix the WinForms references?
There was a problem hiding this comment.
Well the net4.8 variant runs fine for me in WSL, so I assume everything is good on that front.
From the tests I've done it seemed that the System.Windows.Forms reference is functionally equivalent to setting UseWindowsForms.
There was a problem hiding this comment.
From the docs:
When building on a non-Windows platform, the output may not be the same as when building on Windows. In particular, the executable is not marked as a Windows application (which means that it will always launch a console window) and won't have an icon embedded.
CI is Linux so this is a problem.
There was a problem hiding this comment.
From my testing, the .net48 executable looks correct, so this is presumably only an issue for the .NET(6+) version. I suppose the solution would be to build on windows then?
This comment was marked as resolved.
This comment was marked as resolved.
Morilli
force-pushed
the
hammer-and-duct-tape
branch
from
c79e17c
to
11bd5da
Compare
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
Morilli
force-pushed
the
hammer-and-duct-tape
branch
from
11bd5da
to
f2ed1f9
Compare
Morilli
force-pushed
the
hammer-and-duct-tape
branch
from
f2ed1f9
to
dd42fca
Compare
YoshiRulz
changed the title
| @@ -1,6 +1,6 @@ | |||
| <Project Sdk="Microsoft.NET.Sdk"> | |||
| <PropertyGroup> | |||
| <TargetFramework>netstandard2.0</TargetFramework> | |||
| <TargetFrameworks>netstandard2.0;net8.0</TargetFrameworks> | |||
There was a problem hiding this comment.
Just mentioning that this in only necessary because we have BCL backports which get included in the netstandard2.0 assemblies and are invoked as extensions from EmuHawk. All the other libs can target netstandard2.0 only and the build succeeds.
There was a problem hiding this comment.
Relevant, not sure if useful: https://learn.microsoft.com/en-us/dotnet/fundamentals/apicompat/package-validation/overview
Morilli
force-pushed
the
hammer-and-duct-tape
branch
from
6416719
to
a96c557
Compare
This is a proof-of-concept PR multi-targeting both .NET Framework and .NET 8.
.NET 5+ has lots of performance improvements that could immediately benefit us (e.g. #3675).
.NET 5+ does not support WinForms under linux, which means that the .NET Framework version can be used under linux and windows, while the .NET 5+ build is windows-only.
This is still very much at POC level as there will most likely be unexpected issues like differing APIs, dialogs being visually broken etc. Also, no script and command is currently aware of the output folder change:
output/[everything]->output/net4.8/[everything_net4.8]+output/net8.0-windows/[everything_net8.0].Known issues:
net8.0-windows, some waterbox cores (just bsnes?) hardcrash on the first frameadvance. No amount of debug compilation has helped so far, but compiling the waterboxhost with dirty detection disabled fixes this. I'm afraid this may be MAME rom loading regression #3615 all over again.