本文列出了与当前工具的剪裁不兼容的模式。
反射式序列化器
替代方法：无反射序列化程序。
反射的许多用法都可与剪裁兼容，如剪裁警告简介中所述。 但是，序列化工具往往具有反射的复杂用法。 许多此类用途无法在生成时进行分析。 遗憾的是，最佳选择通常是重写系统以使用源生成。
下表列出了基于反射的常用序列化程序及其推荐的替代方法：
| 序列化程序 | 替代方法 |
|---|---|
| Newtonsoft.Json |
生成的源 System.Text.Json |
| System.Configuration.ConfigurationManager | 配置绑定源生成器 |
| System.Runtime.Serialization.Formatters.Binary.BinaryFormatter | 由于 BinaryFormatter 存在安全性和可靠性问题，请避免使用 BinaryFormatter 进行序列化。 |
通过 JIT 生成运行时代码
例如，使用 System.Reflection.Emit 通过 JIT 进行的运行时代码生成与剪裁不兼容。
动态程序集加载和执行
裁剪和程序集的动态加载是支持插件或扩展的系统中常见的问题，通常通过诸如LoadFrom(String)之类的 API 实现。 剪裁依赖于在生成时查看所有程序集，以便知道使用了哪些代码，而不会剪裁这些代码。 大多数插件系统动态加载第三方代码，因此剪裁器无法识别所需的代码。
Windows 平台不兼容
以下部分列出了与 Windows 上的剪裁功能的已知不兼容性。
使用 C++/CLI 进行 NET 编程
使用 C++/CLI 进行 NET 编程 目前不支持剪裁。
内置 COM 封送
替代项：COM 包装器
自 .NET Framework 1.0 以来，自动 COM 封送 已内置到 .NET。 它通过运行时代码分析，在本地 COM 对象与托管 .NET 对象之间实现自动转换。 遗憾的是，裁剪分析无法始终预测需要为自动化 COM 封送保留哪些 .NET 代码。 但是，如果改用 COM 包装器 ，剪裁分析可以保证正确保留所有已用代码。
WPF（Windows Presentation Foundation）
Windows Presentation Foundation （WPF） 框架大量使用反射，某些功能严重依赖于运行时代码检查。 剪裁分析无法保留 WPF 应用程序所需的所有代码。 遗憾的是，剪裁后几乎无法运行 WPF 应用，因此 .NET SDK 中当前禁用了对 WPF 的修整支持。 有关为 WPF 启用剪裁的进度，请参阅 WPF 与剪裁不兼容问题。
Windows 窗体
Windows 窗体框架很少使用反射，但非常依赖于内置 COM 封送。 遗憾的是，几乎没有 Windows 窗体应用可在不使用内置 COM 封送的情况下运行，因此 .NET SDK 中当前已禁用对 Windows 窗体应用的剪裁支持。 有关为 Windows 窗体启用剪裁的进度，请参阅使 WinForms 剪裁兼容问题。
