Share via


Bekende incompatibiliteit bijsnijden

Dit artikel bevat patronen die niet compatibel zijn met bijsnijden met de huidige tooling.

Serializers op basis van weerspiegeling

Alternatief: Serializers zonder reflectie.

Veel toepassingen van weerspiegeling kunnen worden gemaakt die compatibel zijn met bijsnijden, zoals beschreven in Inleiding tot knipwaarschuwingen. Serializers hebben echter vaak complexe toepassingen van reflectie. Veel van deze toepassingen kunnen niet worden geanalyseerd tijdens het bouwen. Helaas is de beste optie vaak om het systeem te herschrijven voor het gebruik van brongeneratie.

De volgende tabel bevat populaire serializers op basis van weerspiegeling en hun aanbevolen alternatieven:

Serializers Alternatief
Newtonsoft.Json Bron gegenereerd System.Text.Json
System.Configuration.ConfigurationManager Configuratiebindingsbrongenerator
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter Migreer weg van BinaryFormatter-serialisatie vanwege de beveiligings- en betrouwbaarheidsfouten.

Runtime-code genereren via JIT

Het genereren van runtimecode via JIT, bijvoorbeeld, System.Reflection.Emit is niet compatibel met bijsnijden.

Dynamisch laden en uitvoeren van assembly

Bijsnijden en dynamisch laden van assembly's is een veelvoorkomend probleem voor systemen die invoegtoepassingen of extensies ondersteunen, meestal via API's zoals LoadFrom(String). Bijsnijden is afhankelijk van het zien van alle assembly's tijdens de build, zodat deze weet welke code wordt gebruikt en niet kan worden afgekapt. De meeste invoegtoepassingssystemen laden code van derden dynamisch, dus het is niet mogelijk voor de trimmer om te bepalen welke code er nodig is.

Incompatibiliteit van Het Windows-platform

De volgende secties bevatten bekende incompatibiliteit met bijsnijden in Windows.

NET programmeren met C++/CLI

Net programmeren met C++/CLI biedt momenteel geen ondersteuning voor bijsnijden.

Ingebouwde COM-marshalling

Alternatief: COM-wrappers

Automatische COM-marshalling is ingebouwd in .NET sinds .NET Framework 1.0. Er wordt gebruikgemaakt van runtimecodeanalyse om automatisch te converteren tussen systeemeigen COM-objecten en beheerde .NET-objecten. Helaas kan het bijsnijden van analyses niet altijd voorspellen welke .NET-code moet worden bewaard voor automatische COM-marshalling. Als COM Wrappers echter worden gebruikt, kan bij het bijsnijden van analyses worden gegarandeerd dat alle gebruikte code correct wordt bewaard.

WPF

Het WPF-framework (Windows Presentation Foundation) maakt aanzienlijk gebruik van reflectie en sommige functies zijn sterk afhankelijk van runtimecode-inspectie. Het is niet mogelijk om analyse bij te snijden om alle benodigde code voor WPF-toepassingen te behouden. Helaas kunnen bijna geen WPF-apps worden uitgevoerd nadat ze zijn ingekort, waardoor ondersteuning voor WPF momenteel is uitgeschakeld in de .NET SDK. Zie dat WPF geen probleem is dat compatibel is met trim voor voortgang bij het inschakelen van knippen voor WPF.

Windows Forms

Het Windows Forms-framework maakt minimaal gebruik van reflectie, maar is sterk afhankelijk van ingebouwde COM-marshalling. Helaas kunnen bijna geen Windows Forms-apps worden uitgevoerd zonder ingebouwde COM-marshalling. Daarom is het bijsnijden van ondersteuning voor Windows Forms-apps momenteel uitgeschakeld in de .NET SDK. Zie WinForms-trim compatibel probleem voor voortgang bij het inschakelen van knippen voor Windows Forms.