Incompatibilidades conocidas de recorte
En este artículo se enumeran los patrones que no son compatibles con el recorte con las herramientas actuales.
Serializadores basados en la reflexión
Alternativa: serializadores sin reflexión.
Muchos usos de la reflexión se pueden hacer compatibles con el recorte, como se describe en Introducción a las advertencias de recorte. Pero los serializadores tienden a tener usos complejos de la reflexión. Muchos de estos usos no se pueden analizar en tiempo de compilación. Desafortunadamente, la mejor opción suele consistir en volver a escribir el sistema para usar la generación de código fuente.
En la siguiente tabla se enumeran los serializadores populares basados en la reflexión y sus alternativas recomendadas:
| Serializadores | Alternativa |
|---|---|
| Newtonsoft.Json | Origen generado System.Text.Json |
| System.Configuration.ConfigurationManager | Generador de origen de enlace de configuración |
| System.Runtime.Serialization.Formatters.Binary.BinaryFormatter | Migre de la serialización BinaryFormatter debido a sus errores de seguridad y confiabilidad. |
Generación de código en runtime mediante JIT
La generación de código en runtime mediante JIT, por ejemplo, a través de System.Reflection.Emit no es compatible con el recorte.
Carga y ejecución de ensamblados dinámicos
El recorte y la carga de ensamblados dinámicos es un problema común para los sistemas que admiten complementos o extensiones, normalmente por medio de API como LoadFrom(String). El recorte se basa en ver todos los ensamblados en tiempo de compilación, por lo que sabe qué código se usa y no se puede recortar. La mayoría de los sistemas de complementos cargan código de terceros de manera dinámica, por lo que no es posible que el recortador identifique qué código es necesario.
Incompatibilidades de la plataforma Windows
En las secciones siguientes se enumeran las incompatibilidades conocidas con el recorte en Windows.
Programación de NET con C++/CLI
Actualmente, la programación de NET con C++/CLI no admite el recorte.
Serialización COM integrada
Alternativa: Contenedores COM
La serialización COM automática se integra en .NET desde .NET Framework 1.0. Usa el análisis de código en tiempo de ejecución para realizar la conversión automática entre objetos COM nativos y objetos de .NET administrados. Desafortunadamente, el análisis de recorte no siempre puede predecir qué código de .NET tiene que conservarse para la serialización COM automática. Pero si en su lugar se utilizan contenedores COM, el análisis de recorte puede garantizar que todo el código usado se conserve correctamente.
WPF
El marco Windows Presentation Foundation (WPF) hace un uso sustancial de la reflexión y algunas características dependen en gran medida de la inspección de código en tiempo de ejecución. No es posible el análisis de recorte a fin de conservar todo el código necesario para las aplicaciones WPF. Desafortunadamente, casi no se pueden ejecutar aplicaciones WPF después del recorte, por lo que la compatibilidad con el recorte para WPF está deshabilitada actualmente en el SDK de .NET. Vea WPF no es compatible con el recorte para ver los avances sobre cómo habilitar el recorte para WPF.
Windows Forms
El marco Windows Forms hace un uso mínimo de la reflexión, pero depende en gran medida de la serialización COM integrada. Desafortunadamente, casi ninguna aplicación de Windows Forms se puede ejecutar sin la serialización COM integrada, por lo que la compatibilidad con el recorte de las aplicaciones de Windows Forms está deshabilitada actualmente en el SDK de .NET. Consulte el problema Hacer compatible el recorte de WinForms para conocer los avances en la habilitación del recorte para Windows Forms.
