진단 및 계측
네이티브 AOT는 CoreCLR과 진단 및 계측 기능의 전부는 아니지만 일부를 공유합니다. CoreCLR의 다양한 진단 유틸리티 선택으로 인해 CoreCLR의 문제를 진단하고 디버그하는 것이 적절한 경우가 있습니다. 자르기 호환 앱은 동작 차이가 없어야 하므로 두 런타임 모두에 조사가 적용되는 경우가 많습니다. 그럼에도 불구하고 일부 정보는 게시 후에만 수집할 수 있으므로 네이티브 AOT는 게시 후 진단 도구도 제공합니다.
.NET 8 네이티브 AOT 진단 지원
다음 표에는 네이티브 AOT 배포에 지원되는 진단 기능이 요약되어 있습니다.
기능 | 완벽하게 지원 | 부분적으로 지원됨 | 지원되지 않음 |
---|---|---|---|
관측 가능성 및 원격 분석 | 부분적으로 지원됨 | ||
개발 시간 진단 | 완전하게 지원됨 | ||
네이티브 디버깅 | 부분적으로 지원됨 | ||
CPU 프로파일링 | 부분적으로 지원됨 | ||
힙 분석 | 지원되지 않음 |
가시성 및 원격 분석
.NET 8부터 네이티브 AOT 런타임은 많은 로깅 및 추적 라이브러리에서 사용되는 네이티브 계층인 EventPipe를 지원합니다. EventSource.WriteEvent
와 같은 API를 통해 EventPipe와 직접 인터페이스하거나 OpenTelemetry와 같이 위에 빌드된 라이브러리를 사용할 수 있습니다. EventPipe 지원을 통해 dotnet-trace, dotnet-counters 및 dotnet-monitor와 같은 .NET 진단 도구가 네이티브 AOT 또는 CoreCLR 애플리케이션과 원활하게 작동할 수 있습니다. EventPipe는 네이티브 AOT의 선택적 구성 요소입니다. EventPipe 지원을 포함하려면 EventSourceSupport
MSBuild 속성을 true
로 설정합니다.
<PropertyGroup>
<EventSourceSupport>true</EventSourceSupport>
</PropertyGroup>
네이티브 AOT는 일부 잘 알려진 이벤트 공급자를 부분적으로 지원합니다. 모든 런타임 이벤트가 네이티브 AOT에서 지원되는 것은 아닙니다.
개발 시간 진단
.NET CLI 도구(dotnet
SDK) 및 Visual Studio는 build
및 publish
에 대해 별도의 명령을 제공합니다. build
(또는 Visual Studio의 경우 Start
)은 CoreCLR을 사용합니다. publish
만 네이티브 AOT 애플리케이션을 만듭니다. 앱을 네이티브 AOT로 게시하면 네이티브 코드로 AOT(Ahead-of-Time) 컴파일된 앱이 생성됩니다. 이전에 언급했듯이 모든 진단 도구가 .NET 8에 게시된 네이티브 AOT 애플리케이션과 원활하게 작동하는 것은 아닙니다. 그러나 개발자는 애플리케이션 빌드 단계에서 모든 .NET 진단 도구를 사용할 수 있습니다. 평소처럼 애플리케이션을 개발, 디버깅 및 테스트하고 마지막 단계 중 하나로 네이티브 AOT를 사용하여 작동하는 앱을 게시하는 것이 좋습니다.
네이티브 디버깅
Visual Studio 내부와 같이 개발 중에 앱을 실행하거나 dotnet run
, dotnet build
또는 dotnet test
를 사용하면 기본적으로 CoreCLR에서 실행됩니다. 그러나 프로젝트 파일에 PublishAot
가 있는 경우 CoreCLR과 네이티브 AOT 간에 동작이 동일해야 합니다. 이러한 특성을 통해 개발 및 테스트에 표준 Visual Studio 관리 디버깅 엔진을 사용할 수 있습니다.
게시 후 네이티브 AOT 애플리케이션은 진정한 네이티브 이진 파일입니다. 관리 디버거는 작동하지 않습니다. 그러나 네이티브 AOT 컴파일러는 네이티브 디버거가 선택한 플랫폼(예: Windows의 WinDbg 또는 Visual Studio, Unix 계열 시스템의 gdb 또는 lldb)에서 디버깅할 수 있는 완전한 네이티브 실행 파일을 생성합니다.
네이티브 AOT 컴파일러는 줄 번호, 형식, 지역 및 매개 변수에 대한 정보를 생성합니다. 네이티브 디버거를 사용하면 스택 추적 및 변수를 검사하고, 원본 줄을 한 단계씩 실행하거나, 줄 중단점을 설정할 수 있습니다.
관리 예외를 디버그하려면 관리 예외가 throw될 때마다 호출되는 RhThrowEx
메서드에 중단점을 설정합니다. 예외는 rcx
또는 x0
레지스터에 저장됩니다. 디버거가 C++ 개체 보기를 지원하는 경우 레지스터를 S_P_CoreLib_System_Exception*
으로 캐스팅하여 예외에 대한 자세한 정보를 볼 수 있습니다.
네이티브 AOT 애플리케이션용 dump 파일을 수집하려면 .NET 8에서 몇 가지 수동 단계가 필요합니다.
Visual Studio 관련 참고 사항
Visual Studio IDE에서 열어서 Visual Studio 디버거에서 네이티브 AOT 컴파일 시작 파일을 시작할 수 있습니다. Visual Studio에서 실행 파일 자체를 열어야 합니다.
예외가 throw될 때마다 중단되는 중단점을 설정하려면 디버그 > Windows 메뉴에서 중단점 옵션을 선택합니다. 새 창에서 새 > 함수 중단점을 선택합니다. 함수 이름으로 RhThrowEx
를 지정하고 언어 옵션을 모든 언어로 둡니다(C#을 선택하지 마세요).
어떤 예외가 throw되었는지 확인하려면 디버깅을 시작하고(디버그 > 디버깅 시작 또는 F5), 조사식 창을 열고(디버그 > Windows > 조사식) 다음 식을 조사식 중 하나로 추가합니다. (S_P_CoreLib_System_Exception*)@rcx
. 이 메커니즘은 RhThrowEx
가 호출될 때 x64 CPU 레지스터 RCX에 throw된 예외가 포함되어 있다는 팩트를 활용합니다. 직접 실행 창에 식을 붙여넣을 수도 있습니다. 구문은 시계와 동일합니다.
기호 파일의 중요도
게시할 때 네이티브 AOT 컴파일러는 실행 파일과 기호 파일을 모두 생성합니다. 네이티브 디버깅 및 프로파일링과 같은 관련 작업에는 네이티브 기호 파일에 대한 액세스가 필요합니다. 이 파일이 없으면 결과가 저하되거나 손상될 수 있습니다.
기호 파일의 이름과 위치에 대한 자세한 내용은 네이티브 디버그 정보를 참조하세요.
CPU 프로파일링
PerfView 및 Perf와 같은 플랫폼별 도구를 사용하여 네이티브 AOT 애플리케이션의 CPU 샘플을 수집할 수 있습니다.
힙 분석
관리 힙 분석은 현재 네이티브 AOT에서 지원되지 않습니다. dotnet-gcdump, PerfView 및 Visual Studio 힙 분석 도구와 같은 힙 분석 도구는 .NET 8의 네이티브 AOT에서 작동하지 않습니다.
.NET
피드백
https://aka.ms/ContentUserFeedback
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요.다음에 대한 사용자 의견 제출 및 보기