Make Expecto libraries target netstandard2.0

[roboz0r]

I did a review of the code and couldn't find anything that would prevent the library from targeting .NET Standard 2.0. I have a .NET Framework project that I'd like to be able to upgrade to the latest version of Expecto. The test projects can't target .NET Standard so I made them dual target net6.0 and net481.

[roboz0r]

I took a few more attempts at this, seems like it's now failing because it now needs both the .NET 10 and .NET 6 SDKs. Happy to keep attempting fixes on this if retargeting Expecto to .NET Standard 2.0 will be approved in principle.

[farlee2121]

closes #524

I think targeting netstandard2.0 would make sense, but I at least want to ask the person who changed it why they did so. I poked around and the change seems to have been @ratsclub

@ratsclub Do you remember why expecto moved from netstandard2.0 to net6.0?

[farlee2121]

I think good faith efforts have been made to understand previous changes and no clear reason has been uncovered.

I'd be comfortable going forward with returning Expecto to netstandard2.0.

[roboz0r]

I changed test projects to dual target net10.0 and net481 on Windows only. build.fsx was changed to a build project as this seems to work better when not using .NET SDK 6.

paket.lock rolled forward a lot of dependencies automatically when changing tfm. Not sure if they should all be pinned in the default group?

[Numpsy]

fwiw I still want to try looking at #498 again at some point (I keep failing to get time for it, but have an upcoming need for some AOT builds of things at work), and as you need to target .NET 8.0+ to get proper support for NativeAOT I might ask about multi-targetting things at .NET 8.0 and .NET Standard 2.0, rather than only .NET Standard?
(It could be changed later, but maybe it's easier to do it in one go?)

[roboz0r]

I can give it a go tomorrow but should be trivial to add the target. Not sure about AOT the big challenge will be F# uses reflection based string printing by default

[farlee2121]

@Numpsy I'd be curious to learn more about your AOT requirements sometime.

I've been digging into improved code location, and it looks like our main option there is heavily reflection-based.

[Numpsy]

Not sure about AOT the big challenge will be F# uses reflection based string printing by default

Yes, the %A stuff is potentially a problem (I do have a cli tool I'm working on at work largely working with an AOT build though)

I'd be curious to learn more about your AOT requirements sometime.

I started looking at it was back and then stopped because my main task at the time was AOT builds of a CLI app where the integration tests are a separate process and don't need to be AOT themselves, and then I started thinking that an AOT build of just a library built for native use should be tested with a native test framework of some sort, but then I now have a case where it would be useful if I could build an existing Expecto test executable natively.. so, I'll give it another try at least.

I've been digging into improved code location

'All' I'd be wanting to do is natively compile and run a test exe - no test explorers or code locations - so hopefully that part isn't a problem.

[ratsclub]

@farlee2121 It has been a while since I did that change. I remember that it was related to not being able to use Tasks properly when targetting netstandard2.0 alone.

[farlee2121]

That's great context. We'll have to be extra mindful to review task behavior. Thanks!