Support for .NET Framework

[AArnott]

How hard would it be to add support for .NET Framework?

[thomhurst]

I've no plans to support net framework. Existing frameworks will all pretty much have existing test suites and for a lot of teams, probably too much effort to migrate those to a new framework for not enough benefit.

Combine that with the fact I'd have to sacrifice newer APIs, or start branching logic with compiler if statements which makes the code harder to maintain.

[thomhurst]

Ah nice - It's been a while since I've used framework now so I'm falling behind on what it can and can't do with new language features!

Seems a lot of my concerns are not actual problems.

In that case - I'm not against targeting net framework too!

In many cases, packages like PolySharp can fill in those missing APIs

Yeah I'm using PolyFill at the moment I think in my SourceGenerators (because they have to target netstandard) - So happy to bring those into the main libraries too. I'd like to keep the dependency tree the same if possible - So not bring in anything more as far as the user is concerned. So Polyfilled libraries are fine because they don't transitively flow through to the consuming project.

props/target to error if the compiler version is low

Good idea. I currently use the props to set the lang to "latest" - But this is obviously different for every sdk.

[AArnott]

In that case - I'm not against targeting net framework too!

Yay.
Do you want to run with or replace what I've already done? Are you interested in my contributing more of the port? I'm quite content if you want to do it all yourself. :)

I'd like to keep the dependency tree the same if possible

Agreed. But .NET brings in System.Text.Json automatically while .NET Framework doesn't, so a PackageReference is required for .NET Framework.
You can simply reference the System.Text.Json package unconditionally and everything is fine, but sooner or later, someone will come along and complain that your dependency tree brings down packages you don't need, and so I've taken to try to filter them to just those frameworks that need them.

[thomhurst]

In that case - I'm not against targeting net framework too!

Yay. Do you want to run with or replace what I've already done? Are you interested in my contributing more of the port? I'm quite content if you want to do it all yourself. :)

If you're happy to keep contributing then I'm happy to let you continue :)

I'd like to keep the dependency tree the same if possible

Agreed. But .NET brings in System.Text.Json automatically while .NET Framework doesn't, so a PackageReference is required for .NET Framework. You can simply reference the System.Text.Json package unconditionally and everything is fine, but sooner or later, someone will come along and complain that your dependency tree brings down packages you don't need, and so I've taken to try to filter them to just those frameworks that need them.

Yep that sounds good to me - If only framework needs the reference, then let's conditionally add it only for framework.

Also, is there much difference in the APIs between netstandard2.0 and net472? Because if not, targeting netstandard might be better as we can also run all the way down to net461(?) I believe

[AArnott]

targeting netstandard might be better as we can also run all the way down to net461(?) I believe

net461 isn't supported any more.
Any .NET Framework less than 4.7.2 doesn't properly support .NET Standard 2.0. The .NET team tried to 'backport' ns2.0 to prior .NET Framework versions and learned it didn't go well. So 4.7.2 was the first 'next version' they could support ns2.0 for properly. So generally speaking, folks should target net472 if they want to consume ns2.0 assemblies to avoid issues.

As for targeting netstandard2.0, I agree if it isn't onerous we could add that or do that instead of .NET Framework specifically. I would generally be in favor of that for libraries. For test frameworks it's less interesting IMO because test projects should target each runtime rather than ns2.0 so that the ns2.0 library they are testing can be executed on each runtime. But I have had (rare) occasions for libraries of test methods to target ns2.0 so they could be referenced by more endpoint test projects that do reference each runtime, but have my own library only compile once. It's not a high priority in any way, but it could be done.

If you're happy to keep contributing then I'm happy to let you continue :)

I'll see what else I can whip up then.

[AArnott]

#1436