Bekannte Kürzungsinkompatibilitäten

In diesem Artikel werden Muster aufgeführt, die mit dem Kürzen mit dem aktuellen Tool nicht kompatibel sind.

Reflexionsbasierte Serialisierungsmodule

Alternative: Spiegelungsfreie Serialisierer.

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 Verwendungszwecke können zum Zeitpunkt der Erstellung nicht analysiert werden. Leider besteht die beste Option häufig darin, das System erneut zu generieren, sodass die Quellengenerierung verwendet wird.

In der folgenden Tabelle sind beliebte spiegelbasierte Serialisierer und ihre empfohlenen Alternativen aufgeführt:

Serialisierungsmodule	Alternative
Newtonsoft.Json	Aus der Quelle generiertSystem.Text.Json
System.Configuration.ConfigurationManager	Quell-Generator für Konfigurationsbindung
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter	Migrieren Sie aufgrund ihrer Sicherheits- und Zuverlässigkeitsfehler von der BinaryFormatter-Serialisierung weg.

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 dynamische Laden von Assemblys ist ein geläufiges Problem bei Systemen, 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 Code von Drittanbietern dynamisch, weshalb der Trimmer nicht ermitteln kann, welcher Code benötigt wird.

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. Die Laufzeitcodeanalyse wird verwendet, um automatisch zwischen nativen 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 jedoch stattdessen COM-Wrappers verwendet werden, kann durch die Kürzungsanalyse garantiert werden, dass der gesamte verwendete Code ordnungsgemäß beibehalten wird.

WPF

Das Windows Presentation Foundation-Framework (WPF) nutzt die Reflexion erheblich, und einige Features sind stark von der Laufzeitcodeüberprüfung abhängig. Es ist nicht möglich, dass die Kürzungsanalyse den gesamten erforderlichen Code für WPF-Anwendungen erhält. Leider können fast keine WPF-Apps nach der Kürzung ausgeführt werden, sodass die Kürzungsunterstützung für WPF im .NET 6 SDK derzeit deaktiviert ist. Informationen zu den Fortschritten beim Aktivieren von Kürzungen für WPF finden Sie unter dem Problem WPF ist nicht mit Kürzungen kompatibel.

Windows Forms

Das Windows Forms-Framework nutzt die Reflexion nur minimal, ist jedoch vom integrierten COM-Marshalling stark abhängig. Leider können fast keine Windows Forms-Apps ohne integriertes COM-Marshalling ausgeführt werden, weshalb der Kürzungssupport für Windows Forms-Apps im .NET SDK derzeit 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.