search

sfryers / MT32Editor

Timbre editor and patch librarian for MT-32 compatible devices
https://www.vogons.org/viewtopic.php?f=29&t=93609
GNU General Public License v3.0
19 stars 0 forks source link

multitargeting to reduce code copy/paste #10

Open maximilien-noal opened 3 months ago

maximilien-noal commented 3 months ago

The 'legacy' and 'current' projects could be merged into one with the use of .NET runtime multitargeting, and macros

The thing is, VS2022 dropped .NET Framework < v4.6 support, so it won't open projects targeting versions older than that. But it can still build them, IIRC.

For opening projects targeting .NET FX before v4.6.X, you need VS2019.

So it might make sense to keep them separate, since you have to open an old version of VS to edit the legacy project. Or you might prefer the current way for other reasons I don't know of.

OTOH, one single sln file and some C# files using macros (#IF __NET_FRAMEWORK then use this code #ELSE use this more recent form of the same code) will reduce the complexity of the code base.

Thoughts ?

sfryers commented 3 months ago

I was actually looking into this a few weeks ago. Except for Midi.cs and the auto-generated Winforms code, the remaining codebase is 99% common across the two versions, so it would seem to make sense to merge them. The current projects on GitHub do share a .sln file but have separate .csproj files. I had to comment out the reference to the legacy project in the .sln file on GitHub in order to prevent CodeQL from failing- I don't think it supports older .NET versions.

I see my options being as follows, and I've not made up my mind yet whether (a) or (b) are worth the effort:

a) Merge everything, as you suggest above, using macros. I think the difficult part here will be managing the two versions of each form- there may end up still being significant duplication of similar code due to this.

b) Move all the common classes into a shared 'MT32Edit-common' subproject, to be compiled as a .dll for the main and legacy projects to import. The complexity here is that the .dll would need to include both versions of the Midi class, and therefore would still need to target both .NET 6.0 and .NET Framework 2.0.

c) Leave it as is, allowing anyone to build the main version on vanilla VS2022 without having to worry about the older dependencies in the legacy version.

As a footnote, I have actually been using VS2022 to compile the legacy version- as long as VS2019 is installed on the same PC, it allows you to add the older frameworks to VS2022:

VS2022_ NET_Framework_2 0