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

  • [アーティクル]

一部のパターンは、トリミングと互換性がないことがわかっています。 これらのパターンの一部は、トリミングと互換性を維持するようにツールが改善されたり、ライブラリが変更されたりすると互換性を維持できるようになります。

組み込みの COM マーシャリング

代替手段: COM ラッパー

.NET Framework 1.0 以降、.NET に自動 COM マーシャリングが組み込まれています。 これは、実行時コード分析を使用して、ネイティブ COM オブジェクトとマネージド .NET オブジェクトの間で自動的に変換を行います。 残念ながら、トリミング分析では、自動 COM マーシャリングのためにどの .NET コードを保持する必要があるかを常に予測できるとは限りません。 ただし、代わりに COM ラッパーを使用すると、トリミング分析により、使用されているすべてのコードが正しく保持されることが保証されます。

WPF

Windows Presentation Foundation (WPF) フレームワークでは、リフレクションがかなり使用されており、一部の機能は実行時コード検査に大きく依存します。 .NET 6 では、トリミング分析で WPF アプリケーションに必要なすべてのコードを保持することはできません。 残念ながら、トリミング後に実行できる WPF アプリはほとんどないため、.NET 6 SDK では WPF のトリミング サポートが無効になっています。

Windows フォーム

Windows フォーム フレームワークでは、リフレクションの使用は最小限に抑えられますが、組み込みの COM マーシャリングに大きく依存します。 .NET 6 では、まだ、ComWrappers を使用するように変換されていません。 残念ながら、組み込みの COM マーシャリングなしで実行できる Windows フォーム アプリはほとんどないため、.NET 6 SDK では Windows フォーム アプリのトリミング サポートが無効になっています。

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

代替手段: ソースによって生成された System.Text.Jsonなど、リフレクションフリーのシリアライザー。

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

動的アセンブリの読み込みと実行

プラグインや拡張機能をサポートする (通常は LoadFrom(String) などの API を使用) システムでは、トリミングと動的アセンブリの読み込みが一般的な問題になります。 トリミングは、ビルド時にすべてのアセンブリを表示することに依存しているため、どのコードが使用されているかを認識し、切り取りを行うことはできません。 ほとんどのプラグイン システムでは、サードパーティのコードが動的に読み込まれるため、トリマーが必要なコードを特定することはできません。