Hoje, anunciamos que a próxima versão após o .NET Core 3.0 será o .NET 5. Este será o próximo grande lançamento da série .NET.
No futuro, haverá apenas um .NET, com o qual você poderá desenvolver Windows, Linux, macOS, iOS, Android, tvOS, watchOS e WebAssembly, entre outros.
Estamos introduzindo novas APIs .NET, recursos de runtime e recursos de linguagem no .NET 5.
A partir do projeto .NET Core, adicionamos cerca de cinquenta mil APIs do .NET Framework à plataforma. O .NET Core 3.0 preenche a maioria das lacunas restantes do .NET Framework 4.8, suportando Windows Forms, WPF e Entity Framework 6. O .NET 5 se baseia nesse trabalho, aproveitando os melhores recursos do .NET Core e Mono para criar uma plataforma. Você pode usá-lo para todo o código .NET moderno.
Pretendemos lançar o .NET 5 em novembro de 2020 e lançar a primeira prévia no primeiro semestre de 2020. Ele será suportado em futuras atualizações para Visual Studio 2019, Visual Studio para Mac e Visual Studio Code.
.NET 5 = .NET Core vNext
.NET 5 é o próximo passo no .NET Core. O projeto visa melhorar o . NET:
- Construa um runtime e framework .NET que possa ser usado em qualquer lugar, com comportamento unificado em tempo de execução e experiência de desenvolvedor.
- Ao aproveitar ao máximo o .NET Core, NET Framework, Xarain e Mono para expandir as capacidades do .NET.
- Construindo o produto a partir de uma única base de código, os desenvolvedores (Microsoft e a comunidade) podem trabalhar juntos e expandir para melhorar todos os cenários.
Esse novo projeto e direção são um ponto de virada importante para o .NET. Com o .NET 5, seu código e arquivos de projeto serão os mesmos, não importa o tipo de aplicação que você esteja construindo. Cada aplicativo tem acesso aos mesmos recursos de runtime, API e idioma. Também inclui melhorias de desempenho no CoreFX, que são feitas quase diariamente.
Tudo o que você ama no .NET Core continuará existindo:
- Código aberto e orientado para a comunidade no GitHub.
- Implementação multiplataforma.
- Suporte para aproveitar recursos específicos da plataforma, como formulários do Windows e WPF no Windows, além de bindings nativos para cada plataforma nativa do Xamarin.
- Alto desempenho.
- Instale lado a lado.
- Arquivos pequenos de projeto (estilo SDK).
- Compatível com interfaces de linha de comando (CLIs).
- Integração com Visual Studio, Visual Studio para Mac e Visual Studio Code.
Também há algumas novidades:
- Você terá mais opções para sua experiência em tempo real (mais sobre isso abaixo).
- A interoperabilidade Java estará disponível em todas as plataformas.
- Múltiplos sistemas operacionais suportarão interoperabilidade Objective-C e Swift.
- O CoreFX será expandido para suportar o antecipação (AOT) para .NET, menor área e suporte a mais sistemas operacionais.
Lançaremos o .NET Core 3.0 em setembro deste ano, o .NET 5 em novembro de 2020, e então pretendemos lançar uma versão principal do arquivo . NET:
Pulamos a versão 4 porque isso confundiria usuários familiarizados com o .NET Framework, que existe há muito tempo com a série 4.x. Além disso, queremos comunicar claramente que o .NET 5 é o futuro da plataforma .NET. Chamá-lo de .NET 5 faz dela a versão mais alta que já lançamos.
Também aproveitamos essa oportunidade para simplificar a nomeação. Achamos que, se apenas um .NET for o melhor, não precisamos de um termo esclarecedor como "Core". O nome mais curto é uma simplificação e também transmite a mensagem de que o .NET 5 possui funcionalidade e comportamento uniformes. Claro, você pode continuar usando o nome ".NET Core" se quiser.
Experiência em tempo real
Mono é a implementação original multiplataforma do .NET. Começou como uma alternativa de código aberto ao .NET Framework e passou a ser específico para dispositivos móveis com a popularidade de iPhone/iOS e dispositivos Android. Mono é um runtime usado como parte do Xamarin.
CoreCLR é um runtime usado como parte do .NET Core. Ele é usado principalmente para suportar aplicações em nuvem, incluindo o maior serviço da Microsoft, e agora também é usado em aplicações de desktop Windows, IoT e aprendizado de máquina.
Em resumo, os runtimes .NET Core e Mono compartilham muitas semelhanças (afinal, ambos são runtimes .NE), mas também possuem recursos únicos valiosos. Faz muito sentido permitir escolher a experiência de execução que você quer. Estamos tornando CoreCLR e Mono intercambiáveis entre si. Vamos tornar tudo tão simples quanto construir um switch para escolher entre diferentes opções de runtime.
As seções a seguir descrevem o foco principal que planejamos usar para o .NET 5. Eles fornecem uma perspectiva clara de como planejamos evoluir esses dois runtimes, individualmente e juntos.
Alta produtividade e alta produtividade
Desde o início, o .NET dependia de compiladores just-in-time (JITs) para converter código de linguagem intermediária (IL) em código de máquina otimizado. Desde então, construímos um runtime gerenciado baseado em JIT, líder na indústria, com alta taxa de transferência e também melhora a experiência dos desenvolvedores, tornando a programação rápida e fácil.
O JIT é ideal para cenários de nuvem e clientes de longa duração. Eles são capazes de gerar código configurado para máquinas específicas, incluindo instruções específicas de CPU. O JIT também pode regenerar métodos em tempo de execução, uma técnica que torna o JIT mais rápido, mas ainda assim oferece a opção de gerar versões altamente otimizadas do código caso se torne um método frequentemente utilizado.
Nossos esforços para fazer ASP.NET Core rodar mais rápido no benchmark Techpower são um ótimo exemplo do poder do JIT e do nosso investimento no CoreCLR. Nossos esforços para reforçar o .NET Core para contêineres também são um testemunho da capacidade do runtime de se adaptar dinamicamente a ambientes restritos.
Ferramentas para desenvolvedores são outro ótimo exemplo de como o JIT é realmente ótimo, como as dotnet watch tools ou editar e continuar. As ferramentas frequentemente precisam compilar e carregar código várias vezes em um único processo sem reiniciar, e precisam fazer isso muito rapidamente.
Desenvolvedores que usam .NET Core ou .NET Framework dependem principalmente do JIT. Portanto, a experiência deve ser familiar.
A experiência padrão para a maioria dos cenários de funcionamento do .NET 5 usa o runtime CoreCLR baseado em JIT. Duas exceções notáveis são iOS e o client Blazor (assembly web), pois ambos exigem compilação nativa antecipada (AOT).
Inicialização rápida, pequena área e baixo uso de memória
A maior parte do projeto Mono tem se concentrado em dispositivos móveis e consoles. Uma característica chave e resultado do projeto é o compilador AOT .NET baseado no projeto de compilador LLVM, líder da indústria. O compilador Mono AOT permite que código .NET seja incorporado a um executável nativo que pode rodar em um computador, assim como o código C++. Aplicações compiladas por AOT podem rodar eficientemente em locais menores e trocar o throughput para inicialização quando necessário.
O projeto Blazor já está usando Mono AOT. Este será um dos primeiros projetos a fazer a transição para o .NET 5. Usamos isso como uma das opções para comprovar esse plano.
Existem dois tipos de soluções AOT:
- Requer uma solução 100% compilada em AOT.
- A maior parte do código é uma solução compilada no AOT, mas o JIT ou interpretadores podem ser usados para padrões de código que não são amigáveis ao AOT (como genéricos). O Mono AOT suporta ambos os casos. A Apple exige o primeiro AOT para iOS e alguns consoles por razões de segurança. O segundo método é uma opção melhor porque oferece as vantagens do AOT e evita algumas desvantagens.
.NET Native é nosso compilador AOT para aplicações Windows UWP, e também é um exemplo do primeiro tipo AOT listado acima. Nesta implementação específica, limitamos a API .NET e os recursos que você pode usar. Aprendemos com essa experiência que as soluções AOT precisam cobrir todos os aspectos das APIs e padrões do .NET.
A compilação AOT ainda é necessária no iOS, assembly web e alguns consoles. Para aplicações que exigem uma inicialização mais rápida ou pouco espaço, tornaremos a compilação AOT uma opção.
O nascimento do projeto
Começamos este projeto em dezembro de 2018 com uma equipe técnica em Boston. Líderes de design da equipe .NET (Mono/Xamarin e .NET Core) e da Unity apresentaram uma variedade de capacidades técnicas e direções arquitetônicas.
Agora estamos avançando com este projeto como uma equipe com um conjunto de entregas. Fizemos muitos progressos em vários projetos desde dezembro:
- Uma camada mínima é definida que define a camada de código gerenciada <-> em tempo de execução com o objetivo de alcançar >99% do código público CoreFX.
- O MonoVM agora pode usar CoreFX e suas bibliotecas de classes.
- Execute todos os testes CoreFX no MonoVM com a implementação CoreFX.
- Execute ASP.NET aplicações Core 3.0 com MonoVM.
- Execute o MonoDevelop no CoreCLR e depois execute o Visual Studio para Mac.
Migre para um único . A implementação do .NET levanta algumas questões importantes: Qual será o framework alvo? As regras de compatibilidade dos pacotes NuGet são as mesmas? Quais cargas de trabalho o SDK .NET 5 deve suportar? Como eu programo para uma arquitetura específica? Ainda precisamos do .NET Standard?
Estamos trabalhando nessas questões agora e em breve compartilharemos o documento de design para que você possa ler e fornecer feedback.
Epílogo
O projeto .NET 5 é uma direção nova e importante e empolgante para o .NET. Você verá o .NET se tornando mais simples, mas também com uma gama maior de recursos e utilidade. Todos os novos desenvolvimentos e recursos farão parte do .NET 5, incluindo novas versões para C#.
Vemos um futuro promissor onde você poderá usar as mesmas APIs e linguagens .NET para direcionar uma ampla variedade de tipos de aplicações, sistemas operacionais e arquiteturas de silício. No Visual Studio, Visual Studio para Mac, Visual Studio Code, Azure DevOps ou na linha de comando, é fácil mudar a configuração da build para criar diferentes aplicações.
Link original:O login do hiperlink está visível.
|
Publicado em 07/05/2019 09:41:27
|
|
|
|
