Bekannte Kürzungsinkompatibilitäten

In diesem Artikel werden Muster aufgeführt, die mit dem Kürzen unter Verwendung der aktuellen Werkzeuge nicht kompatibel sind.

Reflexionsbasierte Serialisierungsmodule

Alternative: Spiegelungsfreie Serializer.

Viele Verwendungsmöglichkeiten der Reflexion können wie unter Einführung in Kürzungswarnungen beschrieben kürzungskompatibel gemacht werden. Serialisierer neigen jedoch zu einer komplexen Verwendung von Reflexion. Viele dieser Verwendungen können zur Buildzeit nicht analysierbar gemacht werden. Leider ist die beste Option häufig, das System neu zu schreiben, um die Quellgenerierung zu verwenden.

In der folgenden Tabelle sind beliebte reflektionsbasierte Serialisierer und ihre empfohlenen Alternativen aufgeführt.

Serialisierer	Alternative
Newtonsoft.Json-	Quelle generiert System.Text.Json
System.Configuration.ConfigurationManager	Quell-Generator für Konfigurationsbindung
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter	Migrieren Sie von der BinaryFormatter-Serialisierung weg, aufgrund ihrer Mängel in puncto Sicherheit und Zuverlässigkeit.

Laufzeitcodegenerierung über JIT

Die Laufzeitcodegenerierung über JIT, z. B. über System.Reflection.Emit, ist mit der Kürzung nicht kompatibel.

Dynamisches Laden und Ausführen von Assemblys

Das Kürzen und das Laden dynamischer Assemblys ist ein häufiges Problem für Systeme, die Plug-Ins oder Erweiterungen unterstützen, in der Regel über APIs wie LoadFrom(String). Das Kürzen beruht darauf, dass alle Assemblys zum Zeitpunkt der Erstellung angezeigt werden, so dass bekannt ist, welcher Code verwendet wird und nicht weggekürzt werden kann. Die meisten Plug-In-Systeme laden Drittanbietercode dynamisch, sodass es für den Trimmer nicht möglich ist, den benötigten Code zu identifizieren.

Inkompatibilitäten der Windows-Plattform

In den folgenden Abschnitten werden bekannte Inkompatibilitäten mit dem Kürzen unter Windows aufgeführt.

NET-Programmierung mit C++/CLI

Die NET-Programmierung mit C++/CLI unterstützt derzeit keine Kürzung.

Integriertes COM-Marshalling

Alternative: COM-Wrapper

Das automatische COM-Marshalling wurde seit .NET Framework 1.0 in .NET integriert. Es verwendet Laufzeitcodeanalyse, um automatisch zwischen systemeigenen COM-Objekten und verwalteten .NET-Objekten zu konvertieren. Leider kann die Kürzungsanalyse nicht immer vorhersagen, welcher .NET-Code für das automatische COM-Marshalling erhalten bleiben muss. Wenn stattdessen COM-Wrapper verwendet werden, kann die Kürzungsanalyse jedoch sicherstellen, dass der gesamte verwendete Code ordnungsgemäß beibehalten wird.

WPF (Windows Presentation Foundation)

Das Windows Presentation Foundation (WPF)-Framework nutzt die Reflexion erheblich, und einige Features sind stark auf die Überprüfung von Laufzeitcode angewiesen. Es ist nicht möglich, die Analyse zu kürzen, um den gesamten erforderlichen Code für WPF-Anwendungen beizubehalten. Leider sind fast keine WPF-Apps nach dem Kürzen ausführbar, sodass die Trimming-Unterstützung für WPF derzeit im .NET SDK deaktiviert ist. Weitere Informationen zum Fortschritt beim Aktivieren der Kürzungsfunktion für WPF finden Sie unter dem Thema Problem, dass WPF nicht trim-kompatibel ist.

Windows Forms

Das Windows Forms-Framework nutzt nur minimale Reflexion, ist jedoch stark auf eingebautes COM-Marshaling angewiesen. Leider können fast keine Windows Forms-Apps ohne integrierte COM-Marshalling ausgeführt werden, sodass die Kürzungsunterstützung für Windows Forms-Apps derzeit im .NET SDK deaktiviert ist. Informationen zu den Fortschritten beim Aktivieren von Kürzungen für Windows Forms finden Sie unter dem Problem Windows Forms mit Kürzungen kompatibel machen.