Nunit: Fin de la prise en charge de .NET Framework 2.0 (publié en 2005)

Bien que je sois entièrement d'accord, je pense que nous devons y aller lentement pour nous assurer que la communauté est consciente que le changement est à venir et peut fournir des commentaires. Nous avons sondé la communauté pour la dernière fois il y a plusieurs années, mais je m'attends à ce que le paysage ait changé depuis lors. J'aimerais également voir la console et le moteur mis à jour vers 3.5 pour les mêmes raisons.

MSTest et xUnit sont actuellement à un minimum de .NET 4.5 et je n'ai vu aucun recul sérieux à ce sujet. Nous pourrions également envisager d'abandonner la prise en charge de la version 4.0 et toutes les solutions de contournement Async que nous avons et exiger la version 4.5 pour les tests. Comme 2.0/3.5, c'est le même CLR. Je suis moins enclin à le faire, mais je le mets sur la table pour discussion.

Il y a plusieurs années, nous avons eu un bogue avec NUnit qui ne prenait pas en charge .NET 3.5. Il a fallu plusieurs mois avant qu'il ne soit signalé, ce qui est une indication de son utilisation. Je m'attends à ce que 2.0 soit extrêmement petit.

Je propose que j'envoie un e-mail à la liste de diffusion NUnit Discuss pour demander les commentaires de toute personne utilisant NUnit pour .NET 2.0 avec un plan pour abandonner le support dans la prochaine version si aucune raison impérieuse ne revient.

Question - S'agit-il d'un changement décisif qui justifierait une version 4.0 ? Nous avons modifié nos versions PCL et .NET Standard sans passer à la 4.0.

J'aime ta proposition.

xUnit 3.0 nécessitera au minimum .NET Framework 4.7.2. https://github.com/xunit/xunit/issues/1732

L'abandon de la prise en charge de net40 en même temps aurait du sens et allégerait notre charge avec des trucs asynchrones. Peut-être devrions-nous envisager de déplacer net45 vers net452 :

La prise en charge de .NET Framework 4, 4.5 et 4.5.1 a pris fin le 12 janvier 2016. Microsoft recommande aux clients d'effectuer une mise à niveau vers .NET Framework 4.5.2 afin de continuer à recevoir une assistance technique et des mises à jour de sécurité. Pour plus d'informations, veuillez visiter la FAQ sur la politique de cycle de vie de prise en charge de .NET Framework https://support.microsoft.com/help/17455.

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

Est-ce un changement décisif qui justifierait une version 4.0 ? Nous avons modifié nos versions PCL et .NET Standard sans passer à la 4.0.

Nous pensons que presque personne ne sera touché. Je préférerais ne pas utiliser le numéro de version 4.0 pour cela, à moins que nous n'en profitions pour apporter d'autres changements de rupture.

/cc @ChrisMaddock qui a récemment travaillé avec des projets net40.

Je ne voudrais pas que nous abandonnions la prise en charge de .NET 4.0. La plupart de nos éléments de bureau sont toujours en .NET 4. Nous y sommes restés longtemps car il s'agissait de la dernière version disponible sur XP. C'est une dette technique maintenant, bien sûr - mais la mise à niveau a un coût. Remarquez, j'ai été vexé lorsque NUnit 3.0 a abandonné la prise en charge du profil client .NET 4.0. ??

Si nous supprimions la version .NET 4.0, les tests .NET 4.0 récupéreraient automatiquement la version .NET 3.5, qui, j'imagine, a une API réduite à plusieurs endroits. Briser les changements à gogo...

Sur .NET 2.0 - Je suis assez apathique. Ma préoccupation serait les bibliothèques prenant en charge plusieurs plates-formes. Je ne suis pas d'accord pour dire que NUnit devrait « encourager » d'autres bibliothèques à abandonner le support, je pense personnellement que la bibliothèque de test devrait être la _dernière_ personnes à abandonner le support - tant qu'il y a des bibliothèques, elles ont besoin de tests ! 🙂 Je ne pense pas non plus que les choix de XUnit/MSTest devraient être pris en compte - la compatibilité descendante est une force de NUnit et une lacune dans l'écosystème que nous comblons. C'est une bonne chose!

Cela dit, .NET 2.0 est _ancien_ maintenant, et je ne serais pas opposé à ce que nous le supprimions - de tels mainteneurs de bibliothèques pourraient verrouiller leurs tests .NET 2.0 pour qu'ils s'exécutent sur NUnit 3.11. Je pense que 7 ans de support passé lorsque Microsoft EOL l'a fait, c'est suffisant !

Je soutiendrais activement la suppression de .NET 2.0 du moteur, où cela nous cause activement des problèmes, par exemple le remplacement de Mono et Remoting. Je ne vois tout simplement pas activement les mêmes obstacles dans le cadre.

@ChrisMaddock c'est une analyse juste de la prise en charge de .NET 4.0 et de ce que cela coûterait, merci. Je suppose que la mise à jour de toutes ces suites de tests vers la cible 4.5 serait également un problème ?

Moins de problème, car nous n'aurions pas à nous soucier des installations .NET sur les machines des utilisateurs. Mais cela signifierait alors que nous ne pourrions pas tester sur une plate-forme que nous "supportons", ce qui n'est pas idéal - nous avons rencontré quelques différences subtiles entre 4,0 et 4,5 au fil des ans.

Intégrez .NET Core et des déploiements autonomes !

J'ai envoyé un e-mail à nunit-discuss demandant à toute personne utilisant .NET 2.0 et qui ne souhaite pas cibler .NET 3.5 dans ses tests de commenter ce problème.

@rprouse Peut-être aussi diffuser la question via le compte twitter nunit (je suppose/espère que "nous" la contrôlons ?)

Excellente idée @mikkelbu , merci. Veuillez retweeter tout le monde, https://twitter.com/nuni/status/1055845383400767490

1 911 impressions sur Twitter pour le tweet et aucune réponse jusqu'à présent... 🤔

Vous avez spécifiquement dit que les gens que nous aimerions entendre sont ceux qui ont tous les deux des tests net20 en développement actif et qui ne veulent pas déplacer le projet de test vers net35, donc peut-être que le nombre 1 911 est une déclaration forte que tout le monde est pas affecté ou heureux de passer à net35?

L'abandon de la prise en charge de 2.0-4.5 semble tout à fait raisonnable ; nous sommes actuellement sur 4.5.2+ et migrons lentement vers 4.6.

:+1: Juste pour clarifier, je pense que nous envisageons uniquement de supprimer .NET Framework 2.0 à ce stade et de conserver nos versions 3.5-4.5 .NET Framework.

Si les gens sont sur .net 2.0 et ne mettent pas à jour le framework, je doute sérieusement qu'ils envisagent même de mettre à jour vers une version plus récente de NUnit. Les anciennes versions fonctionneront toujours, donc je ne vois aucune raison impérieuse de rester sur 2.0, pas même 3.5. Peut-être, peut-être 4.0, mais même pas sûr de ça.

Nous n'avons eu aucun retour négatif ici, dans la liste de discussion ou sur twitter. @nunit/framework-and-engine-team allons-nous avancer avec cela? Comme @ChrisMaddock l'a mentionné, je suis également en faveur de faire de même dans le moteur, mais nous pouvons en discuter là-bas.

Ça fait un mois; sonne bien pour moi. Dois-je PR https://github.com/nunit/nunit/compare/master...jnm2 :drop_net20 ?

Allez-y et soumettez votre PR. Attendons quelques jours les commentaires à son sujet avant de fusionner.

cc @JamesNK pour la sensibilisation, Newtonsoft est une bibliothèque qui, je le sais, utilise toujours .NET 2.0 NUnit.

J'ai vérifié le projet de test NewtonSoft.JSON et il utilise NUnit et a une cible net20 . https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json.Tests/Newtonsoft.Json.Tests.csproj

??

Si vous pensez que c'est mieux pour nunit. Je pourrais toujours exécuter la DLL net20 sur une cible 3.5

Nous ne voulons pas rendre les gens tristes. Prévoyez-vous avoir des utilisateurs qui ont spécifiquement besoin de net20 pendant encore de nombreuses années ?

ℹ (Note générale) Je viens de découvrir ceci lors de l'exécution de tests net35 avec vstest.console.exe 15.9 :

Framework35 n'est pas pris en charge. Pour les projets ciblant .Net Framework 3.5, veuillez utiliser Framework40 pour exécuter des tests en "mode de compatibilité" CLR 4.0.

Aie!

J'ai entendu dire que VS abandonnait la prise en charge du coureur 3.5, mais j'ai vérifié quelques mises à jour il y a quelques instants et il était toujours là. Je suppose que c'est finalement arrivé. Bizarre, je pensais que cela viendrait dans VS 2019 plutôt que dans une mise à jour.

Je pense qu'il a été introduit dans ce PR - Microsoft/vstest#1723, mais il n'est pas mentionné dans les notes de version - https://github.com/Microsoft/vstest-docs/blob/master/docs/releases.md

Il s'agissait du VSTest.Console empaqueté dans .NET Core SDK 2.1.500, piloté via dotnet test . Je pense qu'il a été installé par VS 15.9.

Prévoyez-vous avoir des utilisateurs qui ont spécifiquement besoin de net20 pendant encore de nombreuses années ?

Je ne sais pas. Il n'y a pas de statistiques sur la cible utilisée. De mon point de vue, il n'y a pas beaucoup d'efforts pour garder un objectif net20. Mon plan est de le laisser jusqu'à ce qu'il devienne difficile à entretenir.