Dela via

Komma igång med .NET Native

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 Native-app:

  1. Utveckla en UWP-app (Universal Windows Platform)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 bör 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 universalappmallen för 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 .NET Native-verktygskedjan.

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

Nu kan du skriva C# eller Visual Basic-kod mot den interna .NET-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ökningsbyggen JIT-kompilerade för att snabbt kunna använda kommando F5, medan versionsbyggen kompileras med hjälp av .NET Natives förkompileringsteknik. 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 Native-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 Mitt projekt.

Anmärkning

En översikt över den interna kompileringsprocessen för .NET 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 för .NET Framework, till exempel DataContractSerializer, DataContractJsonSerializeroch XmlSerializer klasser, 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 Serialisering och 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 katalogen som är angiven i textfälten för utdataväg i projektets dialogruta Egenskaper och 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 din app och är säker på att du har eliminerat MissingMetadataException och MissingInteropDataException undantag bör du testa appen som en optimerad .NET Native-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å skrivbordet är en MissingMetadataException-, MissingInteropDataException-eller MissingRuntimeArtifactException- körningsundantag. 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 API:er som förlitar sig på reflektion.

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