Na semana passada, o .NET Core 3.0 (versão 6) foi lançado . Inclui atualizações de compilação de montagem para melhorar o lançamento, melhorar a otimização do tamanho do aplicativo com melhorias no vinculador e EventPipe. Também lançamos novas imagens do Docker para Alpine no ARM64.
Atualizações de WPF e Windows Forms
A equipe do WPF concluiu o processo de publicação da maior parte do código WPF no GitHub . De fato, eles acabaram de publicar o código fonte para quinze compilações . Para aqueles familiarizados com o WPF, os nomes de assembly devem ser muito familiares.
Em alguns casos, os testes ainda estão no backlog e devem ser publicados no 3.0 GA ou antes dele. No entanto, a presença de todo esse código deve permitir que a comunidade do WPF participe totalmente da realização de alterações no WPF. Depois de ler alguns problemas com o GitHub, torna-se óbvio que a comunidade possui seu próprio estoque de novos produtos que você deseja implementar. O que você acha do tópico sombrio?
Alpine Docker Imagens
As imagens do Docker agora estão disponíveis para o .NET Core e o ASP.NET Core no ARM64. Anteriormente, eles estavam disponíveis apenas para x64.
As seguintes imagens podem ser usadas no Dockerfile ou com o docker pull , como mostrado abaixo:
docker pull mcr.microsoft.com/dotnet/core/runtime:3.0-alpine-arm64v8docker pull mcr.microsoft.com/dotnet/core/aspnet:3.0-alpine-arm64v8
Aprimoramentos na tubulação de eventos
O Event Pipe agora suporta multisessionalidade.
Novos contadores de desempenho adicionados:
- % De tempo no GC
- Tamanho da pilha da geração 0
- Tamanho da pilha da geração 1
- Tamanho da pilha da geração 2
- Tamanho da pilha LOH
- Taxa de alocação
- Número de montagens carregadas
- Número de threads ThreadPool
- Taxa de Contenção de Bloqueio do Monitor
- Fila de itens de trabalho ThreadPool
- Taxa de Itens de Trabalho Concluídos ThreadPool
As junções do Profiler agora são implementadas usando a mesma infraestrutura de Event Pipe.
Leia o jogo de contagem de David Fowler para ter uma idéia do que você pode fazer com o canal de eventos para fazer sua própria pesquisa de desempenho ou apenas acompanhar o estado do aplicativo.
Leia dotnet-counters para instalar a ferramenta dotnet-counters.
Otimize seus aplicativos principais do .NET com imagens ReadyToRun
Você pode melhorar o tempo de inicialização de um aplicativo .NET Core compilando as compilações de aplicativos no formato ReadyToRun (R2R). R2R é uma forma de compilação principal (AOT).
Os binários R2R melhoram o desempenho da inicialização, reduzindo a quantidade de trabalho que o JIT precisa realizar quando o aplicativo é carregado. Os binários contêm código de máquina semelhante ao gerado pelo JIT, o que dá ao JIT algum descanso quando o desempenho é mais importante (na inicialização). Os binários no formato R2R são maiores porque contêm código de linguagem intermediária (IL), que ainda é necessário para alguns cenários, e uma versão de máquina do mesmo código para melhorar a inicialização.
O R2R é suportado pelo .NET Core 3.0. Ele não pode ser usado com versões anteriores do .NET Core.
Amostras de desempenho
A seguir, são apresentadas figuras que mostram o desempenho de amostras de aplicativos WPF . O aplicativo foi publicado como autônomo e não usou o vinculador de montagem (discutido posteriormente neste artigo).
Aplicativo somente para IL:
- Tempo de inicialização: 1,9 segundos
- Uso de memória: 69.1 MB
- Tamanho do aplicativo: 150 MB
Com imagens ReadyToRun:
- Tempo de inicialização: 1,3 segundos.
- Uso de memória: 55,7 MB
- Tamanho do aplicativo: 156 MB
Leia mais sobre imagens ReadyToRun
Você pode compilar o R2R, tanto bibliotecas quanto arquivos binários de aplicativos. Atualmente, as bibliotecas só podem ser compiladas no R2R como parte do aplicativo, e não para entrega como um pacote NuGet. Gostaríamos de receber mais feedback sobre se esse cenário é importante.
A compilação de assemblies AOT há muito tempo está disponível como um conceito para .NET, retornando ao .NET Framework e NGEN . Uma desvantagem principal do NGEN é que a compilação deve ser feita nas máquinas clientes usando a ferramenta NGEN. Não é possível gerar imagens NGEN como parte da compilação do aplicativo.
Agora .NET Core. Ele vem com o crossgen , que produz imagens de máquinas no novo formato ReadyToRun . O nome descreve seu valor principal, a saber, que essas imagens de máquinas podem ser criadas como parte de sua montagem e estão "prontas para execução" sem nenhum trabalho adicional nas máquinas clientes. Esta é uma grande melhoria, bem como uma importante vitória na luta contra as mudanças climáticas.
Em termos de compatibilidade, as imagens ReadyToRun são semelhantes às montagens IL, com algumas diferenças importantes.
- Assemblies IL contêm apenas código IL . Eles podem funcionar em qualquer ambiente de tempo de execução que suporte a infraestrutura de destino especificada para este assembly. Por exemplo, a compilação
netstandard2.0 pode ser executada no .NET Framework 4.6+ e .NET Core 2.0+, em qualquer sistema operacional suportado (Windows, macOS, Linux) e arquitetura (Intel, ARM, 32 bits, 64 bits). - Os assemblies R2R contêm IL e código nativo. Eles são compilados para uma versão mínima específica do tempo de execução do .NET Core e do ambiente de tempo de execução (RID). por exemplo, a compilação
netstandard2.0 pode ser compilada com R2R para .NET Core 3.0 e Linux x64. Ele será usado apenas nesta ou em uma configuração compatível (por exemplo, .NET Core 3.1 ou .NET Core 5.0 no Linux x64), porque contém código nativo que só pode ser usado nesse ambiente de tempo de execução.
Instruções
A compilação ReadyToRun está disponível apenas para publicação. A versão de visualização foi lançada no .NET Core 3.0 (Visualização 5).
Para habilitar a compilação ReadyToRun, você precisa:
- Defina o valor da propriedade
PublishReadyToRun como true . - Poste usando o
RuntimeIdentifier exato.
Nota Quando as compilações do aplicativo são compiladas, o código nativo gerado depende da plataforma e da arquitetura (portanto, ao publicar, você deve especificar um RuntimeIdentifier válido).
Aqui está um exemplo:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <OutputType>Exe</OutputType> <TargetFramework>netcoreapp3.0</TargetFramework> <PublishReadyToRun>true</PublishReadyToRun> </PropertyGroup> </Project>
E publicando usando o seguinte comando:
dotnet publish -r win-x64 -c Release
Nota: RuntimeIdentifier pode ser definido no arquivo do projeto.
Nota: No momento, o ReadyToRun é suportado apenas para aplicativos independentes . Ele será adicionado para aplicativos dependentes da estrutura em um anúncio posterior.
A geração de caracteres da máquina pode ser ativada configurando a propriedade PublishReadyToRunEmitSymbols como true . Você não precisa criar caracteres de máquina para fins de depuração. Esses caracteres são úteis apenas para fins de criação de perfil.
Atualmente, o SDK suporta uma maneira de excluir certos conjuntos da compilação em imagens ReadyToRun. Isso pode ser útil nos casos em que as montagens não precisam ser otimizadas para melhorar o desempenho. A exclusão de montagens neste caso pode ajudar a reduzir o tamanho do aplicativo. No caso em que o compilador ReadyToRun falha ao compilar um assembly específico, a solução também pode ser eliminá-lo.
Uma exceção é lançada usando o grupo de elementos PublishReadyToRunExclude:
<ItemGroup> <PublishReadyToRunExclude Include="FilenameOfAssemblyToExclude.dll" /> </ItemGroup>
Compilação entre plataformas / arquitetura
O compilador ReadyToRun ainda não suporta a segmentação cruzada. Você precisa compilar para um determinado objetivo. Por exemplo, se você precisar de imagens R2R para Windows x64, precisará executar o comando de publicação neste ambiente.
Exceções:
- O Windows x64 pode ser usado para compilar imagens do Windows ARM32, ARM64 e x86.
- O Windows x86 pode ser usado para compilar imagens do Windows ARM32.
- O Linux x64 pode ser usado para compilar imagens do Linux ARM32 e ARM64.
Layout da montagem
O NET core 3.0 SDK vem com uma ferramenta que pode reduzir o tamanho do aplicativo analisando a IL e eliminando as compilações não utilizadas.
Com o .NET Core, você sempre pode publicar aplicativos independentes que incluem tudo o que você precisa para executar seu código, sem precisar instalar o .NET no destino de implantação. Em alguns casos, o aplicativo requer apenas um pequeno subconjunto da estrutura e pode ser muito menor, incluindo apenas as bibliotecas usadas.
Usamos o construtor de IL para varrer a IL do seu aplicativo para determinar qual código é realmente necessário e, em seguida, excluir bibliotecas de estrutura não utilizadas. Isso pode reduzir significativamente o tamanho de alguns aplicativos. Como regra, aplicativos de console pequenos como ferramentas obtêm o maior benefício, pois geralmente usam pequenos subconjuntos da estrutura e geralmente se prestam bem ao corte.
Para usar esta ferramenta, defina PublishTrimmed=true no seu projeto e publique o aplicativo independente:
dotnet publish -r <rid> -c Release
A saída da publicação incluirá um subconjunto das bibliotecas de infraestrutura, dependendo do código do aplicativo que está sendo chamado. Para o aplicativo helloworld, o vinculador reduz o tamanho de ~ 68 MB para ~ 28 MB.
Aplicativos ou estruturas (incluindo ASP.NET Core e WPF) que usam reflexão ou funções dinâmicas relacionadas são interrompidas com frequência durante o corte porque o vinculador não tem conhecimento desse comportamento dinâmico e geralmente não pode determinar que tipos de estruturas serão necessárias para reflexão em tempo de execução . Para cortar esses aplicativos, você deve informar o vinculador sobre qualquer tipo necessário para refletir em seu código e em quaisquer pacotes ou ambientes dos quais você depende. Certifique-se de testar seus aplicativos após o corte.
Para obter mais informações sobre o IL Linker, consulte a documentação ou visite o repositório mono / linker .
Nota: Nas versões anteriores do .NET Core, o ILLink.Tasks era enviado como um pacote NuGet externo e fornecia a maioria das mesmas funcionalidades. Não é mais suportado - atualize para o SDK da versão 3.0 mais recente.
Compartilhamento de vinculador e vinculador ReadToRun
Linker Linker e ReadyToRun Linker podem ser usados para o mesmo aplicativo. Em geral, o vinculador torna seu aplicativo menor e, em seguida, o compilador pronto para executar o tornará um pouco maior novamente, mas com um ganho de desempenho significativo. Vale a pena testar várias configurações para entender o efeito de cada opção.
Nota: dotnet / sdk # 3257 impede o compartilhamento de vinculador e ReadyToRun para aplicativos WPF e Windows Forms. Estamos trabalhando para corrigir isso como parte da versão .NET Core 3.0.
Amostra de hospedagem nativa
Publicou recentemente uma amostra de hospedagem nativa . Ele demonstra a melhor abordagem para hospedar o .NET Core em um aplicativo nativo.
Agora, na estrutura do .NET Core 3.0, agora fornecemos funcionalidades comuns aos nossos próprios serviços de hospedagem .NET Core, que antes estavam disponíveis apenas para aplicativos .NET Core gerenciados através de serviços de hospedagem .NET Core fornecidos oficialmente. A funcionalidade está principalmente associada ao carregamento da montagem. Essa funcionalidade deve facilitar a criação de seus próprios serviços de hospedagem que podem usar toda a gama de recursos do .NET Core.
Suporte HTTP / 2 no HttpClient
HTTP / 2 é a versão principal do protocolo HTTP. Alguns dos recursos notáveis do HTTP / 2 são o suporte à compactação de cabeçalho e fluxos totalmente multiplexados em uma única conexão. Embora o HTTP / 2 mantenha a semântica do HTTP (cabeçalhos HTTP, métodos etc.), ele difere do HTTP / 1.x na maneira como os dados são enviados.
HttpClient agora suporta solicitações HTTP / 2. Por padrão, tudo também permanece HTTP / 1.1, mas você pode optar por não usar o HTTP / 2 instalando a versão usando uma solicitação HTTP.
var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001") };
Como alternativa, você pode enviar solicitações HTTP / 2 por padrão, configurando DefaultRequestVersion como HttpClient .
var client = new HttpClient() { BaseAddress = new Uri("https://localhost:5001"), DefaultRequestVersion = new Version(2, 0) };
Como resultado dessa alteração, servidores e clientes devem concordar com a versão do protocolo usada. ALPN (Application-Layer Protocol Negotiation) é uma extensão TLS que permite ao servidor e ao cliente negociar a versão do protocolo usada como parte de sua interação. No entanto, lembre-se de que a maioria dos servidores oferece suporte apenas ao ALPN como a única maneira de estabelecer uma conexão HTTP / 2. Portanto, o HTTP / 2 é negociado pelo HttpClient apenas pela conexão TLS.
Em cenários de desenvolvimento, quando o servidor e o cliente sabem a priori que ambos falarão HTTP / 2 sem criptografia, é possível estabelecer uma conexão HTTP / 2 por texto não criptografado, definindo a opção ou variável de ambiente AppContext . ( DOTNET_SYSTEM_NET_HTTP_SOCKETSHTTPHANDLER_HTTP2UNENCRYPTEDSUPPORT=1 ).
AppContext.SetSwitch("System.Net.Http.SocketsHttpHandler.Http2UnencryptedSupport", true);
Conclusão
Ficaremos muito felizes se você tentar novos recursos. Por favor, reporte problemas ou bugs que encontrar. Você também pode enviar solicitações de novos recursos, mas a implementação deles terá que esperar até a próxima versão.
Agora, estamos muito perto de concluir o trabalho no componente .NET Core 3.0 e agora estamos mudando a atenção da equipe para melhorar a qualidade da versão. Temos meses à frente de correções de bugs e melhorias de desempenho.
A propósito, para a próxima grande atualização, alternaremos as ramificações master nos repositórios do .NET Core. Provavelmente isso acontecerá imediatamente após a Visualização 7 em julho.
Obrigado por testar o .NET Core 3.0. Agradecemos sua ajuda. No momento, estamos focados em tornar a versão final a mais interessante e de alta qualidade para você.