Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo lista padrões incompatíveis com o corte com as ferramentas atuais.
Serializadores baseados em reflexão
Alternativa: serializadores sem reflexão.
Muitos usos de reflexão podem ser compatíveis com o corte, conforme descrito em Introdução aos avisos de corte. No entanto, os serializadores costumam ter usos muito complexos de reflexão. Muitos desses usos não podem ser analisados no tempo de construção. Infelizmente, a melhor opção geralmente é reescrever o sistema para usar a geração de origem.
A tabela a seguir lista serializadores comumente usados baseados em reflexão e suas alternativas recomendadas.
| Serializadores | Alternativa |
|---|---|
| Newtonsoft.Json |
Origem gerada System.Text.Json |
| System.Configuration.ConfigurationManager | Gerador de origem para configuração da associação |
| System.Runtime.Serialization.Formatters.Binary.BinaryFormatter | Migre para longe da serialização BinaryFormatter devido a suas falhas de segurança e confiabilidade. |
Geração de código de runtime por meio do JIT
A geração de código de runtime por meio do JIT, por exemplo, via System.Reflection.Emit é incompatível com o corte.
Carregamento e execução de assembly dinâmico
O corte e o carregamento dinâmico de assemblies são problemas comuns para sistemas que dão suporte a plug-ins ou extensões, frequentemente por meio de APIs como LoadFrom(String). A otimização depende de visualizar todos os assemblies em tempo de compilação, para saber qual código é usado e não pode ser removido. A maioria dos sistemas de plug-in carrega o código de terceiros dinamicamente, portanto, não é possível que o aparador identifique qual código é necessário.
Incompatibilidades da plataforma Windows
As seções a seguir listam incompatibilidades conhecidas com a otimização de código no Windows.
Programação net com C++/CLI
No momento, a programação NET com C++/CLI não dá suporte ao corte.
Marshalling COM interno
Alternativa: Wrappers COM
O COM marshalling automático foi integrado ao .NET desde o .NET Framework 1.0. Ele usa a análise de código de runtime para converter automaticamente entre objetos COM nativos e objetos .NET gerenciados. Infelizmente, a análise de otimização nem sempre pode prever qual código .NET precisará ser preservado para o marshalling COM automático. No entanto, se os Wrappers COM forem usados em vez disso, a análise de corte poderá garantir que todo o código usado será corretamente preservado.
WPF
A estrutura do WPF (Windows Presentation Foundation) faz uso substancial da reflexão e alguns recursos dependem muito da inspeção de código de runtime. Não é possível que a análise de redução preserve todo o código necessário para aplicativos WPF. Infelizmente, quase nenhum aplicativo WPF é executável após a otimização, portanto, o suporte de otimização para WPF está desabilitado no SDK do .NET. Confira o artigo O WPF é incompatível com corte para progredir na habilitação do corte para o WPF.
Windows Forms
A estrutura Windows Forms faz uso mínimo de reflexão, mas depende muito do marshalling COM interno. Infelizmente, quase nenhum aplicativo do Windows Forms é executável sem o marshalling COM interno, portanto, o corte do suporte para aplicativos do Windows Forms está desabilitado no SDK do .NET no momento. Confira o artigo Tornar o WinForms compatível com corte para progredir na habilitação do corte para o Windows Forms.