已知裁剪不兼容

本文列出了与当前工具的剪裁不兼容的模式。

基于反射的序列化程序

替代方法：无反射序列化程序。

反射的许多用法都可与剪裁兼容，如剪裁警告简介中所述。 但是，序列化程序使用反射的方式往往很复杂。 其中的许多用法无法在生成时进行分析。 遗憾的是，最佳选择通常是重写系统来使用源生成。

下表列出了常用的基于反射的序列化程序及其推荐的替代方法：

序列化程序	替代项
Newtonsoft.Json	源生成的 System.Text.Json
System.Configuration.ConfigurationManager	配置绑定源生成器
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter	由于安全性和可靠性缺陷，请不要使用 BinaryFormatter 序列化。

通过 JIT 进行运行时代码生成

例如，使用 System.Reflection.Emit 通过 JIT 进行的运行时代码生成与剪裁不兼容。

动态程序集加载和执行

对于支持插件或扩展（通常通过 LoadFrom(String) 等 API）的系统，剪裁和动态程序集加载是一个常见问题。 剪裁依赖于在生成时查看所有程序集，以便知道使用了哪些代码，而不会剪裁这些代码。 大多数插件系统会动态加载第三方代码，此时剪裁器便无法确定所需的代码。

Windows 平台不兼容性

以下部分列出了与 Windows 上的剪裁功能的已知不兼容性。

使用 C++/CLI 进行 NET 编程

使用 C++/CLI 进行 NET 编程当前不支持剪裁。

内置 COM 封送

替代项：COM 包装器

自 .NET Framework 1.0 开始，.NET 中已内置了自动 COM 封送功能。 该功能使用运行时代码分析在本机 COM 对象和托管 .NET 对象之间自动转换。 遗憾的是，剪裁分析无法始终预测需要保留哪些 .NET 代码以进行自动 COM 封送。 但是，如果改为使用 COM 包装器，剪裁分析便可以保证正确保留所有使用的代码。

WPF

Windows Presentation Foundation (WPF) 框架大量利用反射，而某些功能则很大程度上依赖于运行时代码检查。 剪裁分析无法保留 WPF 应用程序的所有必需代码。 遗憾的是，在剪裁后几乎没有 WPF 应用可运行，因此 .NET SDK 中当前已禁用对 WPF 的剪裁支持。 有关为 WPF 启用剪裁的进度，请参阅 WPF 与剪裁不兼容问题。

Windows 窗体

Windows 窗体框架很少使用反射，但非常依赖于内置 COM 封送。 遗憾的是，几乎没有 Windows 窗体应用可在不使用内置 COM 封送的情况下运行，因此 .NET SDK 中当前已禁用对 Windows 窗体应用的剪裁支持。 有关为 Windows 窗体启用剪裁的进度，请参阅使 WinForms 剪裁兼容问题。