Komma igång med .NET native

Viktigt!

Modernisera UWP-appen med .NET och intern AOT: Om du utvecklar en ny UWP-app eller vill modernisera en befintlig UWP-app rekommenderar vi att du använder UWP-stöd för den senaste .NET med intern AOT i stället för .NET Native. UWP-stöd för moderna .NET är nu allmänt tillgängligt och är projekttypen default för C# UWP-appar i Visual Studio 2026. Detta ger åtkomst till de senaste .NET- och C#-funktionerna, förbättrat stöd för verktyg och felsökning och snabbare byggtider. .NET Native fortsätter att få säkerhets- och tillförlitlighetskorrigeringar men får inga nya funktionsuppdateringar.

Oavsett om du skriver en ny UWP-app eller migrerar en befintlig Windows 8.x-app (tidigare även kallad en Microsoft Store app) kan du följa samma uppsättning procedurer. Följ dessa steg för att skapa en .NET intern app:

  1. Utveckla en Universal Windows Platform (UWP) app och testa felsökningsversionerna av din app för att säkerställa att den fungerar korrekt.

  2. Hantera ytterligare användning av reflektion och serialisering.

  3. Distribuera och testa släppversionerna av din app.

  4. Åtgärda saknade metadata manuelltoch upprepa steg 3 tills alla problem har lösts.

Anmärkning

Om du migrerar en befintlig Windows 8.x-app till .NET Native måste du granska Migrera din Windows 8.x-app till .NET Native.

Steg 1: Utveckla och testa felsökningsversioner av UWP-appen

Oavsett om du utvecklar en ny app eller migrerar en befintlig, följer du samma process som för alla Windows appar.

  1. Skapa ett nytt UWP-projekt i Visual Studio med hjälp av appmallen Universal Windows för Visual C# eller Visual Basic. Som standard är alla UWP-program inriktade på CoreCLR och deras versionsversioner kompileras med hjälp av den .NET interna verktygskedjan.

  2. Observera att det finns några kända kompatibilitetsproblem mellan kompilering av UWP-appprojekt med .NET interna verktygskedjan och utan den. Mer information finns i migreringsguiden för .

Nu kan du skriva C# eller Visual Basic kod mot den .NET interna ytan som körs på det lokala systemet (eller i simulatorn).

Viktigt!

När du utvecklar din app bör du notera all användning av serialisering eller reflektion i koden.

Som standardinställning är felsökningsversioner JIT-kompilerade för att möjliggöra snabb distribution med F5, medan utgivningsversioner kompileras med hjälp av förkompileringstekniken .NET Native. Det innebär att du bör skapa och testa felsökningsversionerna av din app för att säkerställa att de fungerar normalt innan du kompilerar dem med .NET interna verktygskedjan.

Steg 2: Hantera ytterligare reflektions- och serialiseringsanvändning

En runtime-direktivfil, Default.rd.xml, läggs automatiskt till i projektet när du skapar den. Om du utvecklar i C# finns den i mappen Properties i ditt projekt. Om du utvecklar i Visual Basic finns den i mappen project's My Project.

Anmärkning

En översikt över .NET intern kompileringsprocess som ger bakgrund om varför en runtime-direktivfil behövs finns i .NET Native and Compilation.

Runtime-direktivfilen används för att definiera de metadata som din app behöver vid körning. I vissa fall kan standardversionen av filen vara tillräcklig. En del kod som förlitar sig på serialisering eller reflektion kan dock kräva ytterligare poster i körningsdirektivfilen.

serialisering

Det finns två kategorier av serialiserare och båda kan kräva ytterligare poster i körningsdirektivfilen:

  • Icke-reflektionsbaserade serialiserare. Serialiserarna som finns i klassbiblioteket .NET Framework, till exempel klasserna DataContractSerializer, DataContractJsonSerializer och XmlSerializer, förlitar sig inte på reflektion. De kräver dock att koden genereras baserat på objektet som ska serialiseras eller deserialiseras. Mer information finns i avsnittet "Microsoft Serializers" i Serialization and Metadata.

  • Serialiserare från tredje part. Serialiseringsbibliotek från tredje part, varav den vanligaste är Newtonsoft JSON-serialiseraren, är vanligtvis reflektionsbaserade och kräver poster i filen *.rd.xml för att stödja objekt serialisering och deserialisering. Mer information finns i avsnittet "Serialiserare från tredje part" i Serialisering och metadata.

metoder som förlitar sig på reflektion

I vissa fall är användningen av reflektion i kod inte uppenbar. Vissa vanliga API:er eller programmeringsmönster betraktas inte som en del av reflektions-API:et, utan förlitar sig på reflektion för att köras korrekt. Detta omfattar följande typ av instansierings- och metodkonstruktionsmetoder:

För mer information, se API:erna som förlitar sig på reflection.

Anmärkning

Typnamn som används i körningsdirektivfiler måste vara fullständigt kvalificerade. Filen måste till exempel ange "System.String" i stället för "String".

Steg 3: Leverera och testa releaseversionerna av din app

När du har uppdaterat körningsdirektivfilen kan du återskapa och distribuera släppversioner av din app. .NET Native-binärfiler placeras i underkatalogen ILC.out i den katalog som anges i textrutan Build-utdatasökväg i projektets Egenskaper-dialogruta, fliken Kompilera. Binärfiler som inte finns i den här mappen har inte kompilerats med .NET Native. Testa appen noggrant och testa alla scenarier, inklusive felscenarier, på var och en av dess målplattformar.

Om appen inte fungerar korrekt (särskilt om den genererar MissingMetadataException eller MissingInteropDataException undantag vid körning), följer du anvisningarna i nästa avsnitt, Steg 4: Lös saknad metadata manuellt. Om du aktiverar undantag för första chansen kan du hitta dessa buggar.

När du har testat och debuggat felsökningsversionerna av appen och är säker på att du har eliminerat MissingMetadataException och MissingInteropDataException undantag bör du testa appen som en optimerad .NET intern app. Det gör du genom att ändra din aktiva projektkonfiguration från Felsökning till Release.

Steg 4: Lös metadata som saknas manuellt

Det vanligaste felet du stöter på med .NET Native som du inte stöter på på skrivbordet är en körning MissingMetadataException, MissingInteropDataException eller MissingRuntimeArtifactException undantag. I vissa fall kan frånvaron av metadata visa sig i oförutsägbart beteende eller till och med i appfel. I det här avsnittet beskrivs hur du kan felsöka och lösa dessa undantag genom att lägga till direktiv i filen runtime-direktiv. Information om formatet för körningsdirektiv finns i Runtime Directives (rd.xml) Configuration File Reference. När du har lagt till körningsdirektiv bör du distribuera och testa appen igen och lösa eventuella nya MissingMetadataException, MissingInteropDataExceptionoch MissingRuntimeArtifactException undantag tills du inte stöter på några fler undantag.

Tips/Råd

Ange körningsdirektiven på hög nivå så att appen kan vara motståndskraftig mot kodändringar. Vi rekommenderar att du lägger till körningsdirektiv på namnrymds- och typnivå i stället för på medlemsnivå. Observera att det kan finnas en kompromiss mellan återhämtning och större binärfiler med längre kompileringstider.

När du åtgärdar ett undantag för metadata som saknas bör du överväga följande problem:

  • Vad försökte appen göra före undantaget?

    • Var det till exempel databindning, serialisering eller deserialisering av data eller direkt med hjälp av reflektions-API:et?

  • Är det här ett isolerat fall, eller tror du att du kommer att stöta på samma problem för andra typer?

    • Till exempel genereras ett MissingMetadataException undantag när en typ i appens objektmodell serialiseras. Om du känner till andra typer som kommer att serialiseras kan du lägga till körningsdirektiv för dessa typer (eller för deras innehållande namnområden, beroende på hur väl koden är ordnad) samtidigt.

  • Kan du skriva om koden så att den inte använder reflektion?

    • Använder koden till exempel nyckelordet dynamic när du vet vilken typ du kan förvänta dig?

    • Anropar koden en metod som är beroende av reflektion när det finns något bättre alternativ?

Anmärkning

Mer information om hur du hanterar problem som beror på skillnader i reflektion och tillgänglighet för metadata i skrivbordsappar och .NET Native finns i APIs that Rely on Reflection.

Några specifika exempel på hantering av undantag och andra problem som uppstår när du testar din app finns i:

Se även

  • Last updated on