Nunit: Fim do suporte para .NET Framework 2.0 (lançado em 2005)

Embora eu concorde totalmente, acho que precisamos ir devagar para garantir que a comunidade esteja ciente de que a mudança está chegando e possa fornecer feedback. Nossa última pesquisa com a comunidade há vários anos, mas espero que a paisagem tenha mudado desde então. Eu também gostaria de ver o console e o mecanismo atualizados para 3.5 pelos mesmos motivos.

Tanto o MSTest quanto o xUnit estão atualmente no mínimo no .NET 4.5 e não vi nenhum retrocesso sério a isso. Também poderíamos considerar descartar o suporte 4.0 e todas as soluções alternativas Async que temos e exigir 4.5 para testes. Como 2.0 / 3.5, é o mesmo CLR. Estou menos inclinado a fazer isso, mas estou colocando o assunto em discussão.

Vários anos atrás, tivemos um bug com o NUnit que não oferecia suporte ao .NET 3.5. Demorou vários meses até que fosse relatado, o que é uma indicação de quanto é usado. Espero que 2.0 seja incrivelmente pequeno.

Proponho que eu envie um e-mail para a lista de discussão NUnit Discutir pedindo feedback de qualquer pessoa que use o NUnit para .NET 2.0 com um plano de descartar o suporte na próxima versão se nenhum motivo convincente retornar.

Pergunta - Esta é uma alteração significativa que justificaria um lançamento 4.0? Mudamos nossas versões PCL e .NET Standard sem ir para 4.0.

Eu gosto da sua proposta.

O xUnit 3.0 exigirá no mínimo .NET Framework 4.7.2. https://github.com/xunit/xunit/issues/1732

Abandonar o suporte para net40 ao mesmo tempo faria sentido e aliviaria nossa carga com coisas assíncronas. Talvez devêssemos considerar mover net45 para net452:

O suporte para .NET Framework 4, 4.5 e 4.5.1 terminou em 12 de janeiro de 2016. A Microsoft recomenda que os clientes atualizem para .NET Framework 4.5.2 para continuar a receber suporte técnico e atualizações de segurança. Para obter mais informações, visite as Perguntas frequentes sobre a política de ciclo de vida de suporte do .NET Framework https://support.microsoft.com/help/17455.

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

Esta é uma mudança significativa que justificaria um lançamento 4.0? Mudamos nossas versões PCL e .NET Standard sem ir para 4.0.

Achamos que quase ninguém será afetado. Eu preferiria não usar a versão número 4.0 para isso, a menos que aproveitássemos a oportunidade para fazer outras alterações importantes também.

/ cc @ChrisMaddock que trabalhou com projetos net40 recentemente.

Eu não gostaria que abandonássemos o suporte ao .NET 4.0. A maior parte do nosso material de desktop ainda é .NET 4. Nós o corrigimos por um longo tempo por ser a última versão disponível no XP. É uma dívida técnica agora, com certeza - mas a atualização tem um custo. Lembre-se, fiquei chateado quando o NUnit 3.0 abandonou o suporte para o perfil de cliente .NET 4.0. 😉

Se removêssemos a compilação do .NET 4.0, os testes do .NET 4.0 automaticamente pegariam a compilação do .NET 3.5, que imagino ter uma API reduzida em vários lugares. Quebrando muitas mudanças ...

No .NET 2.0 - sou bastante apático. Minha preocupação seria com bibliotecas que suportam múltiplas plataformas. Eu discordo que o NUnit deva 'encorajar' outras bibliotecas a abandonar o suporte, eu pessoalmente acho que a biblioteca de teste deve ser o _último_ povo a abandonar o suporte - contanto que existam bibliotecas por aí, elas precisam ser testadas! 🙂 Eu também não acho que as escolhas de XUnit / MSTest devam ser levadas em consideração - compatibilidade reversa é um ponto forte do NUnit e uma lacuna no ecossistema que preenchemos. Isso é uma coisa boa!

Dito isso, o .NET 2.0 é _antigo_ agora, e eu não me oporia a que o abandonássemos - tais mantenedores de biblioteca poderiam bloquear seus testes do .NET 2.0 para rodar no NUnit 3.11. Acho que há 7 anos de suporte quando o Microsoft EOL tinha isso é suficiente!

Eu apoiaria ativamente a remoção do .NET 2.0 do mecanismo, onde está ativamente nos causando problemas, por exemplo, substituição do Mono e Remoting. Só não vejo ativamente as mesmas barreiras na estrutura.

@ChrisMaddock é uma análise justa do suporte ao .NET 4.0 e quanto custaria, obrigado. Suponho que atualizar todos esses conjuntos de testes para o destino 4.5 também seria um problema?

Menos problema, pois não precisaríamos nos preocupar com as instalações do .NET nas máquinas dos usuários. Mas isso significaria que não poderíamos testar em uma plataforma que 'suportamos', o que não é a ideal - encontramos algumas diferenças sutis entre 4.0 e 4.5 ao longo dos anos.

Traga o .NET Core e implantações independentes!

Enviei um e-mail para nunit-discuss pedindo a qualquer pessoa que esteja usando .NET 2.0 e não queira ter como alvo o .NET 3.5 em seus testes para comentar sobre esse problema.

@rprouse Talvez também transmita a questão através da conta nunit do Twitter (acho / espero que "nós" estejamos controlando isso?)

Excelente ideia @mikkelbu , obrigado. Retweetar para todos, https://twitter.com/nunit/status/1055845383400767490

1.911 impressões no Twitter para o tweet e nenhuma resposta até agora ... 🤔

Você disse especificamente que as pessoas de quem gostaríamos de ouvir são aquelas que têm testes net20 em desenvolvimento ativo e não querem mover o projeto de teste para net35, então talvez o número 1.911 seja uma afirmação forte de que todos estão não afetado ou feliz em mudar para net35?

Abandonar o suporte para 2.0-4.5 parece totalmente razoável; estamos atualmente no 4.5.2+ e migrando lentamente para o 4.6.

: +1: Apenas para esclarecer, acho que estamos apenas considerando descartar o .NET Framework 2.0 neste momento e manter nossas compilações do .NET Framework 3,5–4,5.

Se as pessoas estiverem em .net 2.0 e não atualizarem a estrutura, duvido seriamente que considerassem a atualização para uma versão mais recente do NUnit. As versões mais antigas ainda funcionarão, então não vejo nenhuma razão convincente para permanecer no 2.0, nem mesmo no 3.5. Talvez, talvez 4.0, mas nem tenho certeza disso.

Não tivemos nenhum feedback negativo aqui, na lista de discussão ou no twitter. @ nunit / framework-and-engine-team, devemos prosseguir com isso? Como @ChrisMaddock mencionou, também sou a favor de fazer o mesmo no motor, mas podemos discutir isso lá.

Faz um mês; parece bom para mim. Devo fazer RP https://github.com/nunit/nunit/compare/master...jnm2 : drop_net20?

Vá em frente e envie seu PR. Vamos esperar alguns dias pelos comentários antes de fazer a fusão.

cc @JamesNK para conscientização, Newtonsoft é uma biblioteca que eu conheço ainda usa .NET 2.0 NUnit.

Eu verifiquei o projeto de teste NewtonSoft.JSON e ele está usando o NUnit e tem um destino net20 . https://github.com/JamesNK/Newtonsoft.Json/blob/master/Src/Newtonsoft.Json.Tests/Newtonsoft.Json.Tests.csproj

😢

Se você acha que é melhor para nunit. Eu sempre poderia executar a DLL net20 em um destino 3.5

Não queremos deixar as pessoas tristes. Você prevê ter usuários que precisam especificamente do net20 por muitos anos mais?

ℹ (Observação geral) Acabei de descobrir isso ao executar testes net35 com vstest.console.exe 15.9:

Framework35 não é compatível. Para projetos direcionados ao .Net Framework 3.5, use o Framework40 para executar testes no "modo de compatibilidade" CLR 4.0.

Ai!

Ouvi dizer que o VS estava deixando de oferecer suporte para o runner 3.5, mas verifiquei algumas atualizações atrás e ele ainda estava lá. Acho que finalmente aconteceu. Estranho, pensei que viria no VS 2019, em vez de em uma atualização.

Acho que foi introduzido neste PR - Microsoft / vstest # 1723, mas não é mencionado nas notas de versão - https://github.com/Microsoft/vstest-docs/blob/master/docs/releases.md

Este era o VSTest.Console empacotado no .NET Core SDK 2.1.500, conduzido por dotnet test . Acho que foi instalado pelo VS 15.9.

Você prevê ter usuários que precisam especificamente do net20 por muitos anos mais?

Eu não sei. Não existem estatísticas de qual alvo é usado. Do meu ponto de vista, não há muito esforço em manter uma meta net20. Meu plano é deixá-lo até que seja difícil mantê-lo.