Nunit: Ende der Unterstützung für .NET Framework 2.0 (veröffentlicht im Jahr 2005)

Obwohl ich voll und ganz zustimme, denke ich, dass wir dies langsam angehen müssen, um sicherzustellen, dass die Community sich der bevorstehenden Änderung bewusst ist und Feedback geben kann. Wir haben die Community zuletzt vor einigen Jahren befragt, aber ich gehe davon aus, dass sich die Landschaft seitdem verändert hat. Aus den gleichen Gründen möchte ich auch, dass die Konsole und die Engine auf 3.5 aktualisiert werden.

Sowohl MSTest als auch xUnit haben derzeit mindestens .NET 4.5 und ich habe keine ernsthaften Gegenmaßnahmen dazu gesehen. Wir könnten auch erwägen, die 4.0-Unterstützung und alle Async-Workarounds, die wir darin haben, einzustellen und 4.5 für Tests zu benötigen. Wie 2.0/3.5 ist es die gleiche CLR. Ich bin weniger geneigt, dies zu tun, aber ich lege es zur Diskussion auf den Tisch.

Vor einigen Jahren hatten wir einen Fehler, bei dem NUnit .NET 3.5 nicht unterstützte. Es dauerte mehrere Monate, bis es gemeldet wurde, was ein Hinweis darauf ist, wie viel es verwendet wird. Ich gehe davon aus, dass 2.0 verschwindend klein ist.

Ich schlage vor, dass ich eine E-Mail an die NUnit Discuss-Mailingliste schicke, in der ich um Feedback von allen frage, die NUnit für .NET 2.0 verwenden und planen, den Support in der nächsten Version einzustellen, wenn keine zwingenden Gründe vorliegen.

Frage - Ist dies eine bahnbrechende Änderung, die eine Version 4.0 rechtfertigen würde? Wir haben unsere PCL- und .NET-Standardversionen geändert, ohne auf 4.0 umzusteigen.

Dein Vorschlag gefällt mir.

xUnit 3.0 erfordert mindestens .NET Framework 4.7.2. https://github.com/xunit/xunit/issues/1732

Die gleichzeitige Einstellung der Unterstützung für net40 wäre sinnvoll und würde uns mit asynchronem Zeug entlasten. Vielleicht sollten wir in Betracht ziehen, net45 nach net452 zu verschieben:

Der Support für .NET Framework 4, 4.5 und 4.5.1 endete am 12. Januar 2016. Microsoft empfiehlt Kunden ein Upgrade auf .NET Framework 4.5.2, um weiterhin technischen Support und Sicherheitsupdates zu erhalten. Weitere Informationen finden Sie in den FAQ zu den .NET Framework-Supportlebenszyklusrichtlinien https://support.microsoft.com/help/17455.

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

Ist dies eine bahnbrechende Änderung, die eine Version 4.0 rechtfertigen würde? Wir haben unsere PCL- und .NET-Standardversionen geändert, ohne auf 4.0 umzusteigen.

Wir gehen davon aus, dass kaum jemand betroffen sein wird. Ich würde dafür lieber nicht die Versionsnummer 4.0 nehmen, es sei denn, wir haben die Gelegenheit genutzt, auch andere bahnbrechende Änderungen vorzunehmen.

/cc @ChrisMaddock, der in letzter Zeit mit net40-Projekten gearbeitet hat.

Ich möchte nicht, dass wir die .NET 4.0-Unterstützung einstellen. Die meisten unserer Desktop-Sachen sind immer noch .NET 4. Wir waren lange darauf fixiert, da es die letzte verfügbare Version für XP war. Das sind jetzt natürlich technische Schulden – aber die Aufrüstung hat ihren Preis. Wohlgemerkt, ich war verärgert, als NUnit 3.0 die Unterstützung für das .NET 4.0-Clientprofil eingestellt hat. 😉

Wenn wir den .NET 4.0-Build entfernten, würden .NET 4.0-Tests automatisch den .NET 3.5-Build übernehmen, der meiner Meinung nach an mehreren Stellen eine reduzierte API hat. Veränderungen in Hülle und Fülle...

Auf .NET 2.0 - ich bin ziemlich apathisch. Mein Anliegen wären Bibliotheken, die mehrere Plattformen unterstützen. Ich bin nicht der Meinung, dass NUnit andere Bibliotheken 'ermutigen' sollte, den Support einzustellen. Ich persönlich denke, dass die Testbibliothek die _letzten_ Leute sein sollten, die den Support einstellen - solange es Bibliotheken gibt, müssen sie getestet werden! 🙂 Ich denke auch, dass die Auswahl von XUnit/MSTest keine Rolle spielen sollte - Rückwärtskompatibilität ist eine Stärke von NUnit und eine Lücke im Ökosystem, die wir füllen. Das ist gut!

Alles in allem ist .NET 2.0 jetzt _alt_, und ich wäre nicht abgeneigt, es fallen zu lassen - solche Bibliotheksverwalter könnten ihre .NET 2.0-Tests darauf beschränken, auf NUnit 3.11 zu laufen. Ich denke, dass 7 Jahre Support vergangen sind, wenn Microsoft EOL gemacht hat, ist es ausreichend!

Ich würde das Entfernen von .NET 2.0 aus der Engine aktiv unterstützen, wo es uns aktiv Probleme verursacht, zB Mono- und Remoting-Ersatz. Ich sehe nur nicht aktiv die gleichen Barrieren im Framework.

@ChrisMaddock das ist eine faire Analyse der .NET 4.0-Unterstützung und was es kosten würde, danke. Ich nehme an, die Aktualisierung all dieser Testsuiten auf das Ziel 4.5 wäre auch ein Problem?

Weniger ein Problem, da wir uns nicht um .NET-Installationen auf Benutzercomputern kümmern müssen. Aber das würde dann bedeuten, dass wir nicht auf einer Plattform testen könnten, die wir "unterstützen", was nicht ideal ist - wir haben im Laufe der Jahre ein paar feine Unterschiede zwischen 4,0 und 4,5 festgestellt.

Bringen Sie .NET Core und eigenständige Bereitstellungen ein!

Ich habe eine E-Mail an nunit-discuss gesendet und jeden, der .NET 2.0 verwendet und nicht auf .NET 3.5 in seinen Tests abzielen möchte, gebeten, dieses Problem zu kommentieren.

@rprouse Vielleicht auch die Frage über den Nunit-Twitter-Account senden (ich denke / hoffe, dass "wir" sie kontrollieren?)

Ausgezeichnete Idee @mikkelbu , danke. Bitte retweeten Sie alle, https://twitter.com/nunit/status/1055845383400767490

1.911 Twitter-Impressionen für den Tweet und bisher keine Reaktion...

Sie sagten ausdrücklich, dass die Leute, von denen wir gerne hören würden, diejenigen sind, die net20-Tests in aktiver Entwicklung haben und das Testprojekt nicht auf net35 verschieben möchten, also ist die Zahl 1.911 vielleicht eine starke Aussage, dass jeder das tut entweder unberührt oder gerne zu net35 wechseln?

Die Einstellung der Unterstützung für 2.0-4.5 klingt völlig vernünftig; wir sind derzeit auf 4.5.2+ und migrieren langsam auf 4.6.

:+1: Nur um das klarzustellen, ich denke, wir erwägen derzeit nur, .NET Framework 2.0 zu verwerfen und unsere 3.5–4.5 .NET Framework-Builds beizubehalten.

Wenn die Leute .net 2.0 verwenden und das Framework nicht aktualisieren, bezweifle ich ernsthaft, dass sie überhaupt in Erwägung ziehen, auf eine neuere Version von NUnit zu aktualisieren. Die älteren Versionen werden noch funktionieren, daher sehe ich keinen zwingenden Grund, bei 2.0 zu bleiben, nicht einmal 3.5. Vielleicht, vielleicht 4.0, aber nicht einmal sicher.

Wir haben weder hier, in der Diskussionsliste noch auf Twitter negative Rückmeldungen erhalten. @nunit/framework-and-engine-team sollen wir damit weitermachen? Wie @ChrisMaddock erwähnte, bin ich auch dafür, dasselbe in der Engine zu tun, aber wir können das dort besprechen.

Es ist ein Monat her; klingt gut für mich. Sollte ich PR https://github.com/nunit/nunit/compare/master...jnm2 :drop_net20?

Machen Sie weiter und reichen Sie Ihre PR ein. Warten wir jedoch ein paar Tage auf Kommentare dazu, bevor wir zusammenführen.

cc @JamesNK zur Kenntnisnahme, Newtonsoft ist eine Bibliothek, von der ich weiß, dass sie immer noch .NET 2.0 NUnit verwendet.

Ich habe das NewtonSoft.JSON-Testprojekt überprüft und es verwendet NUnit und hat ein net20 Ziel. https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json.Tests/Newtonsoft.Json.Tests.csproj

😢

Wenn Sie denken, dass es am besten für Nunit ist. Ich könnte die net20-DLL immer auf einem 3.5-Ziel ausführen

Wir wollen die Leute nicht traurig machen. Würden Sie für viele weitere Jahre Nutzer haben, die net20 konkret brauchen?

ℹ (Allgemeiner Hinweis) Ich habe dies gerade beim Ausführen von net35-Tests mit vstest.console.exe 15.9 entdeckt:

Framework35 wird nicht unterstützt. Für Projekte, die auf .Net Framework 3.5 abzielen, verwenden Sie bitte Framework40, um Tests im CLR 4.0-"Kompatibilitätsmodus" auszuführen.

Autsch!

Ich habe gehört, dass VS die Unterstützung für den 3.5-Runner eingestellt hat, aber ich habe vor ein paar Updates nachgesehen und es war immer noch da. Ich glaube, es ist endlich passiert. Seltsam, ich dachte, es würde eher in VS 2019 als in einem Update kommen.

Ich denke, es wurde in dieser PR eingeführt - Microsoft/vstest#1723, aber es wird nicht in den Versionshinweisen erwähnt - https://github.com/Microsoft/vstest-docs/blob/master/docs/releases.md

Dies war das im .NET Core SDK 2.1.500 verpackte VSTest.Console , das über dotnet test gesteuert wurde. Ich denke, es wurde von VS 15.9 installiert.

Würden Sie für viele weitere Jahre Nutzer haben, die net20 konkret brauchen?

Ich weiß nicht. Es gibt keine Statistiken darüber, welches Ziel verwendet wird. Aus meiner Sicht ist es nicht viel Aufwand, ein net20-Ziel einzuhalten. Mein Plan ist es, es zu belassen, bis es zu einer Qual wird, es aufrechtzuerhalten.