已知的修剪不相容性

本文列出與目前工具修剪不相容的模式。

反映型序列化程式

替代方式：無反映序列化程式。

如修剪警告簡介所述，許多反映用途都可以達到修剪相容。 不過，序列化程式往往有複雜的反映用途。 許多這些用途無法在建置階段進行分析。 不幸的是，最佳辦法通常是重寫系統以改用來源產生功能。

下表列出熱門的反映型序列化程式及其建議的替代方案：

序列化程式	替代函式
Newtonsoft.Json	來源產生的 System.Text.Json
System.Configuration.ConfigurationManager	設定繫結來源產生器
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter	因為 BinaryFormatter 序列化的安全性和可靠性缺陷，因此移轉離開。

透過 JIT 產生執行階段程式碼

透過 JIT 產生執行階段程式碼，例如，透過 System.Reflection.Emit 與修剪不相容。

動態元件載入和執行

修剪和動態組件載入是支援外掛程式或擴充功能之系統的常見問題，通常是透過 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 (WPF) 架構會大幅運用反映，而且有些功能高度依賴執行階段程式碼檢查。 修剪分析無法保留 WPF 應用程式的所有必要程式碼。 可惜的是，修剪之後幾乎無法執行任何 WPF 應用程式，因此目前已在 .NET SDK 中停用 WPF 的修剪支援。 如需啟用 WPF 修剪的進度，請參閱 WPF 與修剪不相容的問題。

Windows Forms

Windows Forms 架構會使用最少的反映，但高度依賴內建 COM 封送處理。 可惜的是，若沒有內建 COM 封送處理，幾乎無法執行任何 Windows Forms 應用程式，因此目前已在 .NET SDK 中停用 Windows Forms 應用程式的修剪支援。 如需啟用 Windows Forms 修剪的進度，請參閱讓 WinForms 修剪相容問題。