End support for .NET Framework 2.0 (released in 2005) #3070
Comments
|
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. 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:
https://support.microsoft.com/en-us/lifecycle/search?alpha=.NET Framework 4
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 |
|
@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. |
|
👍 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 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 |
|
😢 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:
|
|
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 |
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. |
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 || NET20where we could haveNET35. We take extra time waiting for tests. And we have more work to do on just net20: nunit/NUnit.System.Linq#12To quote @NN--- from nunit/NUnit.System.Linq#12 (comment):
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:
https://support.microsoft.com/lifecycle/search?alpha=.NET Framework 2.0
The text was updated successfully, but these errors were encountered: