Nunit: End support for .NET Framework 2.0 (released in 2005)

While I agree fully, I think we need to take this slowly to make sure the community is aware that the change is coming and can provide feedback. We last polled the community several years ago, but I expect that the landscape has changed since then. I would also like to see the console and engine updated to 3.5 for the same reasons.

Both MSTest and xUnit are currently at a minimum of .NET 4.5 and I haven't seen any serious pushback to that. We could also consider dropping 4.0 support and all the Async workarounds we have in that and require 4.5 for tests. Like 2.0/3.5, it is the same CLR. I am less inclined to do this, but I am putting it on the table for discussion.

Several years ago we had a bug with NUnit not supporting .NET 3.5. It took several months before it was reported which is an indication on how much it is used. I expect 2.0 is vanishingly small.

I propose that I send out an email to the NUnit Discuss mailing list asking for feedback from anyone using NUnit for .NET 2.0 with a plan to drop support in the next release if no compelling reasons come back.

Question - Is this a breaking change that would warrant a 4.0 release? We've changed our PCL and .NET Standard releases without going to 4.0.

I like your proposal.

xUnit 3.0 will require a minimum of .NET Framework 4.7.2. https://github.com/xunit/xunit/issues/1732

Dropping support for net40 at the same time would make sense and lighten our load with async stuff. Maybe we should consider moving net45 to net452:

Support for .NET Framework 4, 4.5, and 4.5.1 ended on January 12, 2016. Microsoft recommends customers upgrade to .NET Framework 4.5.2 in order to continue to receive technical support and security updates. For more information, please visit the .NET Framework Support Lifecycle Policy FAQ https://support.microsoft.com/help/17455.

https://support.microsoft.com/en-us/lifecycle/search?alpha=.NET Framework 4

Is this a breaking change that would warrant a 4.0 release? We've changed our PCL and .NET Standard releases without going to 4.0.

We think hardly anyone will be affected. I would rather not take the version number 4.0 for this unless we took the opportunity to make other breaking changes too.

/cc @ChrisMaddock who has worked with net40 projects recently.

I'd not like us to drop .NET 4.0 support. Most of our desktop stuff is still .NET 4. We were fixed at it for a long time due to it being the last version available on XP. It's technical debt now, sure - but upgrading has a cost. Mind you, I was miffed when NUnit 3.0 dropped support for .NET 4.0 client profile. 😉

If we removed the .NET 4.0 build, then .NET 4.0 tests would automatically pick up the .NET 3.5 build, which I imagine has a reduced API in a number of places. Breaking changes galore...

On .NET 2.0 - I'm fairly apathetic. My concern would be libraries supporting multiple platforms. I disagree that NUnit should 'encourage' other libraries to drop support, I personally think that the test library should be the _last_ people to drop support - as long as there's libraries out there, they need testing! 🙂 I also don't think the choices of XUnit/MSTest should factor in - backwards compat is a strength of NUnit, and a gap in the ecosystem we fill. That's a good thing!

All that said, .NET 2.0 is _old_ now, and I wouldn't be averse to us dropping it - such library maintainers could lock their .NET 2.0 tests to running on NUnit 3.11. I think 7 years support past when Microsoft EOL'd it is sufficient!

I'd actively support removing .NET 2.0 from the engine, where it's actively causing us problems e.g. Mono and Remoting replacement. I just don't actively see the same barriers in the framework.

@ChrisMaddock that's a fair analysis of .NET 4.0 support and what it would cost, thanks. I suppose updating all of those test suites to target 4.5 would be an issue too?

Less of an issue, as we wouldn’t need to worry about .NET installations on user machines. But then that would mean we couldn’t test on a platform we 'support', which isn’t ideal - we’ve hit a few subtle differences between 4.0 and 4.5 over the years.

Bring in .NET Core and self-contained deployments!

I've sent out an email to nunit-discuss asking anyone that is using .NET 2.0 and who does not want to target .NET 3.5 in their tests to comment on this issue.

@rprouse Perhaps also broadcast the question via the nunit twitter account (I guess/hope that "we" are controlling it?)

Excellent idea @mikkelbu, thanks. Please retweet everyone, https://twitter.com/nunit/status/1055845383400767490

1,911 twitter impressions for the tweet and no response so far... 🤔

You did specifically say that the folks that we'd like to hear from are the folks that both have net20 tests in active development and do not want to move the test project to net35, so maybe the 1,911 number is a strong statement that everyone is either unaffected or happy to move to net35?

Dropping support for 2.0-4.5 sounds entirely reasonable; we are currently on 4.5.2+ and are slowly migrating to 4.6.

:+1: Just to clarify, I think we are only considering dropping .NET Framework 2.0 at this point and keeping our 3.5–4.5 .NET Framework builds.

If people are on .net 2.0 and don't update the framework, I seriously doubt they would even consider updating to a newer version of NUnit. The older versions will still work, so I don't see any compelling reason to stay on 2.0, not even 3.5. Perhaps, perhaps 4.0, but not even sure about that.

We've had no negative feedback here, in the discussion list or on twitter. @nunit/framework-and-engine-team shall we move forward with this? As @ChrisMaddock mentioned, I'm also in favor of doing the same in the engine, but we can discuss that there.

It's been a month; sounds good to me. Should I PR https://github.com/nunit/nunit/compare/master...jnm2:drop_net20?

Go ahead and submit your PR. Let's wait a few days for comments on it before we merge though.

cc @JamesNK for awareness, Newtonsoft is one library that I know still uses .NET 2.0 NUnit.

I checked the NewtonSoft.JSON test project and it is using NUnit and has a net20 target. https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json.Tests/Newtonsoft.Json.Tests.csproj

😢

If you think it is best for nunit. I could always run the net20 DLL on a 3.5 target

We don't want to make folks sad. Would you foresee having users that specifically need net20 for many more years?

ℹ (General note) I just discovered this when running net35 tests with vstest.console.exe 15.9:

Framework35 is not supported. For projects targeting .Net Framework 3.5, please use Framework40 to run tests in CLR 4.0 "compatibility mode".

Ouch!

I heard that VS was dropping support for the 3.5 runner, but I checked a couple of updates ago and it was still there. I guess it finally happened. Odd, I thought it would come in VS 2019 rather than in an update.

I think it was introduced in this PR - Microsoft/vstest#1723, but it is not mentioned in the release notes - https://github.com/Microsoft/vstest-docs/blob/master/docs/releases.md

This was the VSTest.Console packaged in .NET Core SDK 2.1.500, driven via dotnet test. I think it was installed by VS 15.9.

Would you foresee having users that specifically need net20 for many more years?

I don't know. There aren't any statistics of what target is used. From my point of view there isn't much effort in keeping a net20 target. My plan is to leave it until it becomes a pain to maintain.