既知のトリミングの非互換性

この記事では、現在のツールとのトリミングと互換性のないパターンの一覧を示します。

リフレクション ベースのシリアライザー

別の方法: リフレクションフリーのシリアライザー。

「トリム警告の概要」で説明されているように、多くのリフレクションの用途をトリミングと互換性を持たせることができます。 ただし、シリアライザーではリフレクションが複雑に使用される傾向があります。 これらの用途の多くは、ビルド時に分析できません。 残念ながら、多くの場合、ソース生成を使用するようにシステムを書き換えるのが最善の方法です。

次の表に、一般的なリフレクション ベースのシリアライザーとその推奨される代替手段を示します。

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 マーシャリングに大きく依存しています。 残念ながら、組み込みの COM マーシャリングなしで実行できる Windows フォーム アプリはほとんどないため、現在、.NET SDK では Windows フォーム アプリのトリミングのサポートは無効になっています。 Windows フォームでトリミングを可能にするための進捗については、WinForms のトリミング対応を目指す問題を参照してください。