Diagnostyka i instrumentacja
Natywna funkcja AOT udostępnia niektóre, ale nie wszystkie funkcje diagnostyki i instrumentacji z pełnym środowiskiem uruchomieniowym platformy .NET. Aplikacje zgodne z przycinanie nie powinny mieć różnic behawioralnych, dlatego badania często mają zastosowanie do obu środowisk uruchomieniowych. W związku z tym czasami właściwe jest diagnozowanie i debugowanie problemów w pełnym środowisku uruchomieniowym platformy .NET, ponieważ ma on bogaty wybór dostępnych narzędzi diagnostycznych. Niemniej jednak niektóre informacje można zebrać tylko po opublikowaniu, dlatego natywna usługa AOT udostępnia również narzędzia diagnostyczne po opublikowaniu.
Natywna obsługa diagnostyczna usługi AOT
W poniższej tabeli przedstawiono podsumowanie funkcji diagnostycznych obsługiwanych w przypadku wdrożeń natywnych funkcji AOT:
| Funkcja | W pełni obsługiwane | Zaimportowano częściowo | Nieobsługiwane |
|---|---|---|---|
| Obserwowanie i telemetria | Częściowo obsługiwane | ||
| Diagnostyka czasu programowania | W pełni obsługiwane | ||
| Debugowanie natywne | Częściowo obsługiwane | ||
| Profilowanie procesora CPU | Częściowo obsługiwane | ||
| Analiza stert | Nieobsługiwane |
Obserwowanie i telemetria
Od platformy .NET 8 środowisko uruchomieniowe natywnej AOT obsługuje platformę EventPipe, która jest warstwą podstawową używaną przez wiele bibliotek rejestrowania i śledzenia. Interfejs z interfejsem EventPipe można połączyć bezpośrednio za pośrednictwem interfejsów API, takich jak EventSource.WriteEvent lub można użyć bibliotek utworzonych na początku, takich jak OpenTelemetry. Obsługa interfejsu EventPipe umożliwia również korzystanie z narzędzi diagnostycznych platformy .NET, takich jak dotnet-trace, dotnet-counters i dotnet-monitor , bezproblemowa praca z natywnymi aplikacjami środowiska uruchomieniowego AOT lub pełnymi aplikacjami środowiska uruchomieniowego platformy .NET. EventPipe jest opcjonalnym składnikiem w natywnej usłudze AOT. Aby uwzględnić obsługę elementu EventPipe, ustaw EventSourceSupport właściwość MSBuild na truewartość .
<PropertyGroup>
<EventSourceSupport>true</EventSourceSupport>
</PropertyGroup>
Natywna funkcja AOT zapewnia częściową obsługę niektórych dobrze znanych dostawców zdarzeń. Nie wszystkie zdarzenia środowiska uruchomieniowego są obsługiwane w natywnej usłudze AOT.
Diagnostyka czasu programowania
Narzędzia interfejsu wiersza polecenia platformy .NET (dotnet zestaw SDK) i program Visual Studio oferują oddzielne polecenia dla i build publish. build (lub Start w programie Visual Studio) używa pełnego środowiska uruchomieniowego platformy .NET. Tworzy tylko publish natywną aplikację AOT. Publikowanie aplikacji jako natywnej funkcji AOT powoduje utworzenie aplikacji, która została skompilowana przed czasem (AOT) do kodu natywnego. Jak wspomniano wcześniej, nie wszystkie narzędzia diagnostyczne działają bezproblemowo z opublikowanymi natywnymi aplikacjami AOT na platformie .NET 8. Jednak wszystkie narzędzia diagnostyczne platformy .NET są dostępne dla deweloperów podczas etapu tworzenia aplikacji. Zalecamy tworzenie, debugowanie i testowanie aplikacji w zwykły sposób oraz publikowanie aplikacji roboczej z natywną usługą AOT jako jednym z ostatnich kroków.
Debugowanie natywne
Po uruchomieniu aplikacji podczas programowania, na przykład w programie Visual Studio lub dotnet rundotnet buildw systemie , domyślnie dotnet testjest uruchamiana w pełnym środowisku uruchomieniowym platformy .NET. Jeśli PublishAot jednak występuje w pliku projektu, zachowanie powinno być takie samo między pełnym środowiskiem uruchomieniowym platformy .NET a natywną funkcją AOT. Ta cecha umożliwia używanie standardowego aparatu debugowania zarządzanego programu Visual Studio do programowania i testowania.
Po opublikowaniu natywne aplikacje AOT są natywnymi plikami binarnymi. Zarządzany debuger nie będzie nad nimi działać. Jednak natywny kompilator AOT generuje w pełni natywne pliki wykonywalne, które natywne debugery mogą debugować na wybranej platformie (na przykład WinDbg lub Visual Studio w systemach windows i gdb lub lldb w systemach przypominających system Unix).
Kompilator natywnej funkcji AOT generuje informacje o numerach wierszy, typach, ustawieniach lokalnych i parametrach. Natywny debuger umożliwia inspekcję śledzenia i zmiennych stosu, przechodzenie do wierszy źródłowych lub ustawianie punktów przerwania wiersza.
Aby debugować wyjątki zarządzane, ustaw punkt przerwania w metodzie RhThrowEx , która jest wywoływana za każdym razem, gdy jest zgłaszany wyjątek zarządzany. Wyjątek jest przechowywany w rejestrze rcx lub x0 . Jeśli debuger obsługuje wyświetlanie obiektów języka C++, możesz rzutować rejestr, aby S_P_CoreLib_System_Exception* wyświetlić więcej informacji o wyjątku.
Zbieranie pliku zrzutu dla natywnej aplikacji AOT obejmuje kilka ręcznych kroków na platformie .NET 8.
Uwagi specyficzne dla programu Visual Studio
Plik wykonywalny skompilowany przy użyciu natywnego środowiska AOT można uruchomić w debugerze programu Visual Studio, otwierając go w środowisku IDE programu Visual Studio. Musisz otworzyć plik wykonywalny w programie Visual Studio.
Aby ustawić punkt przerwania, który ulega awarii za każdym razem, gdy zostanie zgłoszony wyjątek, wybierz opcję Punkty przerwania z menu Debuguj > system Windows. W nowym oknie wybierz pozycję Nowy > punkt przerwania funkcji . Określ RhThrowEx jako nazwę funkcji i pozostaw opcję Język we wszystkich językach (nie wybieraj języka C#).
Aby zobaczyć, jaki wyjątek został zgłoszony, rozpocznij debugowanie (Debuguj > rozpocznij debugowanie debugowania lub F5), otwórz okno Obserwowanie (Debugowanie > usługi Windows > Watch) i dodaj następujące wyrażenie jako jedno z zegarków: (S_P_CoreLib_System_Exception*)@rcx. Ten mechanizm wykorzystuje fakt, że w czasie RhThrowEx jest wywoływany rejestr procesorów x64 RCX zawiera zgłoszony wyjątek. Możesz również wkleić wyrażenie do okna Natychmiastowe; składnia jest taka sama jak w przypadku zegarków.
Znaczenie pliku symboli
Podczas publikowania kompilator natywny AOT tworzy zarówno plik wykonywalny, jak i plik symboli. Debugowanie natywne i powiązane działania, takie jak profilowanie, wymagają dostępu do natywnego pliku symboli. Jeśli ten plik nie jest obecny, może wystąpić obniżenie wydajności lub uszkodzenie wyników.
Aby uzyskać informacje o nazwie i lokalizacji pliku symboli, zobacz Native debug information (Informacje o debugowaniu natywnym).
Profilowanie procesora CPU
Narzędzia specyficzne dla platformy, takie jak PerfView i Perf , mogą służyć do zbierania przykładów procesora CPU dla natywnej aplikacji AOT.
Analiza stert
Analiza sterty zarządzanej nie jest obecnie obsługiwana w natywnej usłudze AOT. Narzędzia do analizy sterty, takie jak dotnet-gcdump, PerfView i narzędzia analizy sterty programu Visual Studio, nie działają w natywnym AOT na platformie .NET 8.
