New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

End support for .NET Framework 2.0 (released in 2005) #3070

Open
jnm2 opened this Issue Oct 18, 2018 · 14 comments

Comments

Projects
None yet
6 participants
@jnm2
Contributor

jnm2 commented Oct 18, 2018

Supporting a minimum of net20 instead of net35 increases the complexity of our development. We have NUnit.System.Linq and define our own System.Action and write NET35 || NET20 where we could have NET35. We take extra time waiting for tests. And we have more work to do on just net20: nunit/NUnit.System.Linq#12

To quote @NN--- from nunit/NUnit.System.Linq#12 (comment):

If I have library for .NET 2.0 , then tests should be .NET 2.0 .
I don't think there is anyone who still uses 2.0.
The only issue is that many libraries have support for all .NET versions starting from 2.0.

Maybe if NUnit stops supporting net20, it could give other libraries the nudge they need to drop net20 as well. If a net20 project is still in development, it should upgrade to a newer .NET Framework and fix any bugs. I expect bugs in practice to be extremely rare. If a net20 project is not still in development, it shouldn't have a reason to upgrade to newer NUnit framework or runners.

I'm still in favor of supporting net35 (released in 2008) because I know of real-world projects that run using CLR v2 (supports up to net35) and I wouldn't be confident running tests for that on the CLR v4 engine. Also, VSTest is still shipping with a net35 runner. However, I do wonder if dropping this support could have a beneficial ripple effect.

Lastly, the .NET Framework 2.0 product is no longer supported by its own manufacturer:

Support for .NET Framework 2.0 ended on July 12, 2011. .NET 3.5 SP1 is the only supported service pack level after this date. We strongly encourage customers to migrate to .NET Framework 3.5 SP1. For more information, please visit the .NET Framework Support Lifecycle Policy FAQ

https://support.microsoft.com/lifecycle/search?alpha=.NET Framework 2.0

@rprouse

This comment has been minimized.

Member

rprouse commented Oct 18, 2018

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.

@jnm2

This comment has been minimized.

Contributor

jnm2 commented Oct 18, 2018

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.

@jnm2

This comment has been minimized.

Contributor

jnm2 commented Oct 18, 2018

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

@ChrisMaddock

This comment has been minimized.

Member

ChrisMaddock commented Oct 18, 2018

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.

@rprouse

This comment has been minimized.

Member

rprouse commented Oct 18, 2018

@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?

@ChrisMaddock

This comment has been minimized.

Member

ChrisMaddock commented Oct 19, 2018

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!

@rprouse

This comment has been minimized.

Member

rprouse commented Oct 25, 2018

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.

@mikkelbu

This comment has been minimized.

Member

mikkelbu commented Oct 25, 2018

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

@rprouse

This comment has been minimized.

Member

rprouse commented Oct 26, 2018

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

@rprouse

This comment has been minimized.

Member

rprouse commented Oct 31, 2018

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

@jnm2

This comment has been minimized.

Contributor

jnm2 commented Oct 31, 2018

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?

@indy-singh

This comment has been minimized.

Contributor

indy-singh commented Oct 31, 2018

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

@jnm2

This comment has been minimized.

Contributor

jnm2 commented Nov 1, 2018

👍 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.

@OsirisTerje

This comment has been minimized.

Member

OsirisTerje commented Nov 4, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment