已知裁剪不兼容

  • 项目

有一些模式已知与剪裁不兼容。 随着工具的改进或库修改为与剪裁兼容，其中的某些模式可能会变为与剪裁兼容。

内置 COM 封送

替代项：COM 包装器

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

WPF

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

Windows 窗体

Windows 窗体框架很少使用反射，但非常依赖于内置 COM 封送。 在 .NET 6 中，尚未将其转换为使用 ComWrappers。 遗憾的是，几乎没有 Windows 窗体应用可在不使用内置 COM 封送的情况下运行，因此 .NET 6 SDK 中已禁用对 Windows 窗体应用的剪裁支持。

基于反射的序列化程序

替代项：无反射的序列化程序，如源生成的 System.Text.Json。

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

动态程序集加载和执行

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