Diagnostik och instrumentation
Intern AOT delar vissa, men inte alla, diagnostik- och instrumentationsfunktioner med den fullständiga .NET-körningen. Appar som är trimkompatibla bör inte ha beteendeskillnader, så undersökningar gäller ofta för båda körningarna. Därför är det ibland lämpligt att diagnostisera och felsöka problem i den fullständiga .NET-körningen, eftersom den har ett omfattande urval av tillgängliga diagnostikverktyg. En del information kan dock bara samlas in efter publicering, så intern AOT tillhandahåller även diagnostikverktyg efter publicering.
Stöd för intern AOT-diagnostik
I följande tabell sammanfattas diagnostikfunktioner som stöds för interna AOT-distributioner:
| Funktion | Stöds fullt ut | Delvis stöd | Stöds inte |
|---|---|---|---|
| Observerbarhet och telemetri | Delvis stöd | ||
| Diagnostik för utvecklingstid | Stöds fullt ut | ||
| Intern felsökning | Delvis stöd | ||
| CPU-profilering | Delvis stöd | ||
| Heapanalys | Stöds ej |
Observerbarhet och telemetri
Från och med .NET 8 stöder den interna AOT-körningen EventPipe, som är basskiktet som används av många loggnings- och spårningsbibliotek. Du kan gränssnitt med EventPipe direkt via API:er som EventSource.WriteEvent eller så kan du använda bibliotek som bygger på toppen, till exempel OpenTelemetry. EventPipe-stöd tillåter också att .NET-diagnostikverktyg som dotnet-trace, dotnet-counters och dotnet-monitor fungerar sömlöst med interna AOT- eller fullständiga .NET-körningsprogram. EventPipe är en valfri komponent i intern AOT. Om du vill inkludera EventPipe-stöd anger du EventSourceSupport egenskapen MSBuild till true.
<PropertyGroup>
<EventSourceSupport>true</EventSourceSupport>
</PropertyGroup>
Intern AOT ger delvis stöd för vissa välkända händelseprovidrar. Alla körningshändelser stöds inte i intern AOT.
Diagnostik för utvecklingstid
.NET CLI-verktygen (dotnet SDK) och Visual Studio erbjuder separata kommandon för build och publish. build (eller Start i Visual Studio) använder den fullständiga .NET-körningen. Skapar endast publish ett internt AOT-program. När du publicerar din app som intern AOT skapas en app som har kompilerats i förväg (AOT) till inbyggd kod. Som tidigare nämnts fungerar inte alla diagnostikverktyg sömlöst med publicerade interna AOT-program i .NET 8. Alla .NET-diagnostikverktyg är dock tillgängliga för utvecklare under programskapandefasen. Vi rekommenderar att du utvecklar, felsöker och testar programmen som vanligt och publicerar arbetsappen med intern AOT som ett av de sista stegen.
Intern felsökning
När du kör din app under utveckling, till exempel i Visual Studio, eller med dotnet run, dotnet buildeller dotnet test, körs den som standard på den fullständiga .NET-körningen. Men om PublishAot det finns i projektfilen bör beteendet vara detsamma mellan den fullständiga .NET-körningen och intern AOT. Med den här egenskapen kan du använda visual studio-standardmotorn för hanterad felsökning för utveckling och testning.
Efter publiceringen är interna AOT-program sanna interna binärfiler. Det hanterade felsökningsprogrammet fungerar inte på dem. Den interna AOT-kompilatorn genererar dock helt inbyggda körbara filer som interna felsökningsprogram kan felsöka på valfri plattform (till exempel WinDbg eller Visual Studio i Windows och gdb eller lldb på Unix-liknande system).
Den interna AOT-kompilatorn genererar information om radnummer, typer, lokalbefolkningen och parametrar. Med det interna felsökningsprogrammet kan du inspektera stackspårning och variabler, gå in i eller över källlinjer eller ange radbrytningspunkter.
Om du vill felsöka hanterade undantag anger du en brytpunkt för RhThrowEx metoden, som anropas när ett hanterat undantag utlöses. Undantaget lagras i rcx eller x0 registreras. Om felsökningsprogrammet stöder visning av C++-objekt kan du skicka registret till S_P_CoreLib_System_Exception* för att se mer information om undantaget.
Insamling av en dumpfil för ett internt AOT-program omfattar några manuella steg i .NET 8.
Visual Studio-specifika anteckningar
Du kan starta en intern AOT-kompilerad körbar fil under Visual Studio-felsökningsprogrammet genom att öppna den i Visual Studio IDE. Du måste öppna själva körbara filen i Visual Studio.
Om du vill ange en brytpunkt som bryts när ett undantag utlöses väljer du alternativet Brytpunkter på Menyn Felsöka > Windows . I det nya fönstret väljer du Ny > funktions brytpunkt. Ange RhThrowEx som funktionsnamn och lämna alternativet Språk på Alla språk (välj inte C#).
Om du vill se vilket undantag som utlöstes börjar du felsöka (Felsök > startfelsökning eller F5), öppnar bevakningsfönstret (Felsök > Windows > Watch) och lägger till följande uttryck som en av klockorna: (S_P_CoreLib_System_Exception*)@rcx. Den här mekanismen utnyttjar det faktum att vid den tidpunkten RhThrowEx anropas innehåller x64 CPU-registret RCX undantaget som genereras. Du kan också klistra in uttrycket i fönstret Omedelbart. syntaxen är densamma som för klockor.
Symbolfilens betydelse
När du publicerar skapar den interna AOT-kompilatorn både en körbar fil och en symbolfil. Intern felsökning och relaterade aktiviteter som profilering kräver åtkomst till den interna symbolfilen. Om den här filen inte finns kan du ha försämrat eller brutit resultat.
Information om symbolfilens namn och plats finns i Intern felsökningsinformation.
CPU-profilering
Plattformsspecifika verktyg som PerfView och Perf kan användas för att samla in CPU-exempel på ett internt AOT-program.
Heapanalys
Hanterad heapanalys stöds för närvarande inte i intern AOT. Analysverktyg för heapanalys som dotnet-gcdump, PerfView och Visual Studio fungerar inte i intern AOT i .NET 8.
