本文列出與目前工具修剪不相容的模式。
反射式序列化器
替代方案：無需反射的序列化器。
許多反射的用法都可以達到修剪相容性，如 修剪警告簡介中所述。 不過，序列化器通常會有複雜的反射用法。 許多這些用途無法在建置時間進行分析。 不幸的是，最佳選項通常是重寫系統以使用來源產生。
下表列出熱門的反映型串行化程式及其建議的替代方案：
| 序列化器 | 替代方案 |
|---|---|
| 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 以來，自動 COM 封送 處理已內建至 .NET。 它利用執行時程式碼分析，自動在原生 COM 物件與受管理的 .NET 物件之間轉換。 不幸的是，裁剪分析不一定能準確預測自動 COM 封送處理需要保留哪些 .NET 代碼。 不過，如果改用 COM 包裝器，修剪分析可以保證正確保留所有已使用的程式代碼。
WPF
Windows Presentation Foundation（WPF）框架大量使用反射，且部分功能高度依賴執行時程式碼檢查。 修剪分析無法保留 WPF 應用程式所需的所有代碼。 不幸的是，修剪之後幾乎無法執行 WPF 應用程式，因此目前在 .NET SDK 中已停用 WPF 的修剪支援。 如需啟用 WPF 修剪的進度，請參閱 WPF 與修剪不相容 的問題。
Windows Forms
Windows Forms 架構對反射的使用量最小，但高度依賴內建的 COM 封送處理。 不幸的是，幾乎沒有 Windows Forms 應用程式能在沒有內建的 COM 封送處理的情況下運行，因此目前在 .NET SDK 中已停用 Windows Forms 應用程式的修剪功能。 如需啟用 Windows Forms 裁剪的進度，請參閱 讓 WinForms 裁剪相容 議題。
