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 pueden ser 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 ser volver a escribir el sistema para usar la generación de origen.

En la tabla siguiente se enumeran los serializadores populares basados en reflexión y sus alternativas recomendadas:

Serializadores	Alternativa
Newtonsoft.Json	Fuente generada System.Text.Json
System.Configuration.ConfigurationManager	Generador de código fuente con vinculación de configuración
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter	Migre de la serialización BinaryFormatter debido a sus errores de seguridad y fiabilidad.

Generación de código en tiempo de ejecución mediante JIT

La generación de código en tiempo de ejecución mediante JIT, por ejemplo, a través de System.Reflection.Emit, no es compatible con el recorte.

Carga y ejecución dinámicas de ensamblados

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 dinámicamente, por lo que no es posible que el optimizador 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 convertir automáticamente entre objetos COM nativos y objetos .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. Sin embargo, si se usan COM Wrappers en su lugar, el análisis de recorte puede garantizar que todo el código utilizado se conserve correctamente.

WPF (Windows Presentation Foundation)

El marco de 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 que el análisis de recorte conserve 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 tema Hacer que WinForms sea compatible con recortes para obtener información sobre el progreso en la habilitación del recorte para Windows Forms.