Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Den här artikeln innehåller mönster som inte är kompatibla med trimning med den aktuella verktygsuppsättningen.
Reflektionsbaserade serialiserare
Alternativ: Reflektionsfria serialiserare.
Många användningar av reflektion kan göras trimningskompatibla, enligt beskrivningen i Introduktion till trimningsvarningar. Serialiserare tenderar dock att använda reflektion på ett komplext sätt. Många av dessa användningsområden kan inte analyseras vid byggtiden. Tyvärr är det bästa alternativet ofta att skriva om systemet för att använda källgenerering.
I följande tabell visas populära reflektionsbaserade serialiserare och deras rekommenderade alternativ:
| Serialiserare | Alternativ |
|---|---|
| Newtonsoft.Json |
Källa som genererats System.Text.Json |
| System.Configuration.ConfigurationManager | Generator för källkod som binder konfigurationer |
| System.Runtime.Serialization.Formatters.Binary.BinaryFormatter | Migrera bort från BinaryFormatter-serialisering på grund av dess säkerhets- och tillförlitlighetsfel. |
Körkodgenerering med hjälp av JIT
Körningskodgenerering via JIT, till exempel via System.Reflection.Emit, är inte kompatibel med trimning.
Dynamisk sammanställningsladdning och sammanställningskörning
Trimning och dynamisk assemblering är ett vanligt problem för system som stöder plugins eller tillägg, vanligtvis via API:er som LoadFrom(String). Trimning bygger på att se alla programmoduler under byggprocessen, så att den vet vilken kod som används och inte kan trimmas bort. De flesta plugin-system läser in kod från tredje part dynamiskt, så det är inte möjligt för trimmern att identifiera vilken kod som behövs.
Inkompatibiliteter för Windows-plattformen
I följande avsnitt listas kända inkompatibiliteter med trimning i Windows.
NET-programmering med C++/CLI
NET-programmering med C++/CLI stöder för närvarande inte trimning.
Inbyggd COM-marshallering
Alternativ: COM-omslutning
Automatisk COM-marshalling har byggts in i .NET sedan .NET Framework 1.0. Den använder körningskodanalys för att automatiskt konvertera mellan interna COM-objekt och hanterade .NET-objekt. Tyvärr kan trimningsanalys inte alltid förutsäga vilken .NET-kod som behöver bevaras för automatisk COM-marshalling. Men, om COM Wrappers används i stället kan trimningsanalysen garantera att all kod som används bevaras korrekt.
WPF (Windows Presentation Foundation)
WPF-ramverket (Windows Presentation Foundation) gör omfattande användning av reflektion, och vissa funktioner är starkt beroende av granskning av kod vid körning. Det går inte att trimma analys för att bevara all nödvändig kod för WPF-program. Tyvärr är nästan inga WPF-appar körbara efter trimning, så trimningsstöd för WPF är för närvarande inaktiverat i .NET SDK. Se problemet med att WPF inte är trimkompatibelt för information om framsteg vid aktivering av trimning för WPF.
Windows-formulär
Windows Forms-ramverket använder minimal reflektion, men är starkt beroende av inbyggd COM-marshalling. Tyvärr kan nästan inga Windows Forms-appar köras utan inbyggd COM-marshalling, så trimningsstöd för Windows Forms-appar är inaktiverat i .NET SDK för närvarande. Se Göra WinForms trimningskompatibla-problemet för att följa framstegen med att aktivera trimning för Windows Forms.