Nunit: Fin del soporte para .NET Framework 2.0 (lanzado en 2005)

Si bien estoy totalmente de acuerdo, creo que debemos tomar esto con calma para asegurarnos de que la comunidad esté al tanto de que se avecina el cambio y pueda proporcionar comentarios. La última vez que encuestamos a la comunidad fue hace varios años, pero espero que el panorama haya cambiado desde entonces. También me gustaría ver la consola y el motor actualizados a 3.5 por las mismas razones.

Tanto MSTest como xUnit están actualmente en un mínimo de .NET 4.5 y no he visto ningún retroceso serio a eso. También podríamos considerar eliminar la compatibilidad con 4.0 y todas las soluciones de Async que tenemos en eso y requerir 4.5 para las pruebas. Como 2.0 / 3.5, es el mismo CLR. Me inclino menos a hacer esto, pero lo estoy poniendo sobre la mesa para discutirlo.

Hace varios años tuvimos un error con NUnit que no era compatible con .NET 3.5. Pasaron varios meses antes de que se informara, lo que es una indicación de cuánto se usa. Espero que 2.0 sea extremadamente pequeño.

Propongo que envíe un correo electrónico a la lista de correo de NUnit Discuss solicitando comentarios de cualquiera que use NUnit para .NET 2.0 con un plan para dejar el soporte en la próxima versión si no surgen razones convincentes.

Pregunta : ¿Es este un cambio importante que justificaría una versión 4.0? Hemos cambiado nuestras versiones estándar de PCL y .NET sin pasar a la 4.0.

Me gusta tu propuesta.

xUnit 3.0 requerirá un mínimo de .NET Framework 4.7.2. https://github.com/xunit/xunit/issues/1732

Dejar el soporte para net40 al mismo tiempo tendría sentido y aligeraría nuestra carga con cosas asincrónicas. Quizás deberíamos considerar mover net45 a net452:

El soporte para .NET Framework 4, 4.5 y 4.5.1 finalizó el 12 de enero de 2016. Microsoft recomienda a los clientes que actualicen a .NET Framework 4.5.2 para seguir recibiendo soporte técnico y actualizaciones de seguridad. Para obtener más información, visite las preguntas frecuentes sobre la política del ciclo de vida de soporte de .NET Framework https://support.microsoft.com/help/17455.

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

¿Es este un cambio importante que justificaría una versión 4.0? Hemos cambiado nuestras versiones estándar de PCL y .NET sin pasar a la 4.0.

Creemos que casi nadie se verá afectado. Preferiría no tomar la versión 4.0 para esto a menos que aprovechemos la oportunidad para hacer otros cambios importantes también.

/ cc @ChrisMaddock que ha trabajado con proyectos net40 recientemente.

No me gustaría que dejáramos de admitir .NET 4.0. La mayor parte de nuestro material de escritorio sigue siendo .NET 4. Estuvimos arreglados durante mucho tiempo debido a que era la última versión disponible en XP. Ahora es una deuda técnica, claro, pero la actualización tiene un costo. Eso sí, me molestó cuando NUnit 3.0 eliminó el soporte para el perfil de cliente .NET 4.0. 😉

Si elimináramos la compilación de .NET 4.0, las pruebas de .NET 4.0 recogerían automáticamente la compilación de .NET 3.5, que imagino que tiene una API reducida en varios lugares. Rompiendo cambios en abundancia ...

En .NET 2.0: soy bastante apático. Mi preocupación serían las bibliotecas que soportan múltiples plataformas. No estoy de acuerdo con que NUnit deba "alentar" a otras bibliotecas a que abandonen el soporte. Personalmente, creo que la biblioteca de prueba debería ser la _última_ gente en abandonar el soporte; siempre que haya bibliotecas, ¡necesitan pruebas! 🙂 Tampoco creo que las opciones de XUnit / MSTest deban tener en cuenta: la compatibilidad hacia atrás es una fortaleza de NUnit y una brecha en el ecosistema que llenamos. ¡Eso es bueno!

Dicho todo esto, .NET 2.0 es _antiguo_ ahora, y no me opondría a que lo dejáramos; tales mantenedores de bibliotecas podrían bloquear sus pruebas de .NET 2.0 para que se ejecuten en NUnit 3.11. ¡Creo que 7 años de soporte pasados ​​cuando Microsoft EOL lo hizo es suficiente!

Apoyaría activamente la eliminación de .NET 2.0 del motor, donde nos está causando problemas, por ejemplo, el reemplazo de Mono y Remoting. Simplemente no veo activamente las mismas barreras en el marco.

@ChrisMaddock ese es un análisis justo del soporte de .NET 4.0 y lo que costaría, gracias. Supongo que actualizar todos esos conjuntos de pruebas para apuntar a 4.5 también sería un problema.

Un problema menor, ya que no tendríamos que preocuparnos por las instalaciones de .NET en las máquinas de los usuarios. Pero eso significaría que no podríamos probar en una plataforma que 'admitimos', lo cual no es ideal; hemos encontrado algunas diferencias sutiles entre 4.0 y 4.5 a lo largo de los años.

¡Traiga .NET Core e implementaciones autónomas!

Envié un correo electrónico a nunit-discuss pidiendo a cualquiera que esté usando .NET 2.0 y que no quiera apuntar a .NET 3.5 en sus pruebas que comenten sobre este problema.

@rprouse Quizás también transmita la pregunta a través de la cuenta de twitter de nunit (¿supongo / espero que "nosotros" la controlemos?)

Excelente idea @mikkelbu , gracias. Retwittee a todos, https://twitter.com/nunit/status/1055845383400767490

1.911 impresiones de Twitter para el tweet y hasta ahora no hay respuesta ... 🤔

Dijiste específicamente que las personas de las que nos gustaría escuchar son las personas que tienen pruebas de net20 en desarrollo activo y no quieren mover el proyecto de prueba a net35, por lo que tal vez el número 1,911 sea una afirmación sólida de que todos están ¿No se ha visto afectado o está feliz de pasar a net35?

Dejar el soporte para 2.0-4.5 suena completamente razonable; actualmente estamos en 4.5.2+ y estamos migrando lentamente a 4.6.

: +1: Solo para aclarar, creo que solo estamos considerando eliminar .NET Framework 2.0 en este momento y mantener nuestras compilaciones de .NET Framework 3.5–4.5.

Si las personas están en .net 2.0 y no actualizan el marco, dudo seriamente que consideren la posibilidad de actualizar a una versión más nueva de NUnit. Las versiones anteriores seguirán funcionando, así que no veo ninguna razón convincente para permanecer en 2.0, ni siquiera 3.5. Quizás, quizás 4.0, pero ni siquiera estoy seguro de eso.

No hemos tenido comentarios negativos aquí, en la lista de discusión o en Twitter. @ nunit / framework-and-engine-team ¿seguimos adelante con esto? Como mencionó @ChrisMaddock , también estoy a favor de hacer lo mismo en el motor, pero podemos discutir eso allí.

Ha pasado un mes; suena bien para mí. ¿Debo PR https://github.com/nunit/nunit/compare/master...jnm2 : drop_net20?

Continúe y envíe su PR. Sin embargo, esperemos unos días para recibir comentarios antes de fusionarnos.

cc @JamesNK para el conocimiento, Newtonsoft es una biblioteca que sé que todavía usa .NET 2.0 NUnit.

Verifiqué el proyecto de prueba NewtonSoft.JSON y está usando NUnit y tiene un objetivo net20 . https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json.Tests/Newtonsoft.Json.Tests.csproj

😢

Si crees que es mejor para nunit. Siempre podría ejecutar la DLL net20 en un objetivo 3.5

No queremos entristecer a la gente. ¿Prevería tener usuarios que necesiten específicamente net20 durante muchos años más?

ℹ (Nota general) Acabo de descubrir esto al ejecutar pruebas net35 con vstest.console.exe 15.9:

Framework35 no es compatible. Para proyectos destinados a .Net Framework 3.5, utilice Framework40 para ejecutar pruebas en el "modo de compatibilidad" CLR 4.0.

¡Ay!

Escuché que VS estaba abandonando el soporte para el corredor 3.5, pero verifiqué un par de actualizaciones hace y todavía estaba allí. Supongo que finalmente sucedió. Curioso, pensé que vendría en VS 2019 en lugar de una actualización.

Creo que se introdujo en este PR - Microsoft / vstest # 1723, pero no se menciona en las notas de la versión - https://github.com/Microsoft/vstest-docs/blob/master/docs/releases.md

Este fue el VSTest.Console empaquetado en .NET Core SDK 2.1.500, impulsado a través de dotnet test . Creo que fue instalado por VS 15.9.

¿Prevería tener usuarios que necesiten específicamente net20 durante muchos años más?

No sé. No hay estadísticas de qué objetivo se utiliza. Desde mi punto de vista, no hay mucho esfuerzo para mantener un objetivo net20. Mi plan es dejarlo hasta que se convierta en un dolor de mantener.