Znane przycinanie niezgodności

W tym artykule wymieniono wzorce niezgodne z przycinaniem bieżącego narzędzia.

serializatory oparte na Emocje ionach

Alternatywa: serializatory bez Emocje ionów.

Wiele zastosowań odbicia może być zgodnych z przycinaniem, zgodnie z opisem w temacie Wprowadzenie do ostrzeżeń dotyczących przycinania. Jednak serializatory mają tendencję do złożonych zastosowań odbicia. Wiele z tych zastosowań nie może być analizowalnych w czasie kompilacji. Niestety, najlepszą opcją jest często ponowne zapisywanie systemu w celu użycia generowania źródła.

W poniższej tabeli wymieniono popularne serializatory oparte na odbiciu i ich zalecane alternatywy:

Serializers	Alternatywne rozwiązanie
Newtonsoft.Json	Wygenerowane źródło System.Text.Json
System.Configuration.ConfigurationManager	Generator źródła powiązania konfiguracji
System.Runtime.Serialization.Formatters.Binary.BinaryFormatter	Migracja z dala od serializacji BinaryFormatter ze względu na jego wady zabezpieczeń i niezawodności.

Generowanie kodu środowiska uruchomieniowego za pośrednictwem trybu JIT

Generowanie kodu w czasie wykonywania za pośrednictwem trybu JIT, na przykład za pośrednictwem System.Reflection.Emit , jest niezgodne z przycinaniem.

Dynamiczne ładowanie i wykonywanie zestawu

Przycinanie i dynamiczne ładowanie zestawów jest typowym problemem dla systemów obsługujących wtyczki lub rozszerzenia, zwykle za pośrednictwem interfejsów API, takich jak LoadFrom(String). Przycinanie polega na wyświetlaniu wszystkich zestawów w czasie kompilacji, więc wie, który kod jest używany i nie można go przyciąć. Większość systemów wtyczek dynamicznie ładuje kod innej firmy, więc nie jest możliwe, aby trimmer zidentyfikował potrzebny kod.

Niezgodności platformy Windows

W poniższych sekcjach wymieniono znane niezgodności z przycinaniem w systemie Windows.

Programowanie na platformie NET za pomocą języka C++/interfejsu wiersza polecenia

Programowanie na platformie NET w języku C++/CLI obecnie nie obsługuje przycinania.

Wbudowane marshaling COM

Alternatywa: Otoki COM

Automatyczne marshallowanie COM zostało wbudowane na platformie .NET od wersji .NET Framework 1.0. Używa analizy kodu w czasie wykonywania, aby automatycznie konwertować między natywnymi obiektami COM i zarządzanymi obiektami platformy .NET. Niestety analiza przycinania nie zawsze może przewidzieć, jaki kod platformy .NET musi zostać zachowany do automatycznego marshalingu COM. Jeśli jednak zamiast tego są używane otoki COM, analiza przycinania może zagwarantować, że cały używany kod zostanie poprawnie zachowany.

WPF

Struktura Windows Presentation Foundation (WPF) znacznie wykorzystuje odbicie, a niektóre funkcje są mocno uzależnione od inspekcji kodu w czasie wykonywania. Nie można przycinać analizy, aby zachować cały niezbędny kod dla aplikacji WPF. Niestety, prawie żadne aplikacje WPF nie są uruchamiane po przycinaniu, więc obsługa przycinania WPF jest obecnie wyłączona w zestawie SDK platformy .NET. Zobacz WPF nie jest problemem zgodnym z przycinaniem, aby uzyskać postęp włączania przycinania dla WPF.

Windows Forms

Platforma Windows Forms zapewnia minimalne wykorzystanie odbicia, ale jest w dużym stopniu zależna od wbudowanego marshalingu COM. Niestety, prawie żadne aplikacje windows Forms nie są uruchamiane bez wbudowanego marshalingu COM, więc przycinanie obsługi aplikacji Windows Forms jest obecnie wyłączone w zestawie SDK platformy .NET. Zobacz Make WinForms trim compatible issue for progress on enabling trimming for Windows Forms (Wprowadzanie zgodności funkcji WinForms, aby uzyskać informacje o postępie włączania przycinania formularzy systemu Windows).