내 자신의 추적 수신기를 사용하여 파일에 메시지를 출력하고 있습니다. 좋은 성능을 위해, 필자는 App.Config에서 autoflush를 false로 설정했습니다. 그래서 나는 기본 버퍼가 예기치 않은/비정상적인 프로그램 종료를 만나더라도 항상 디스크에 플러시 될 수 있도록해야합니다. 디버깅하는 동안 프로그램을 종료하십시오. 나는 이것이 일반적인 문제일지도 모른다고 생각했다. 우아한 해결책이 있는가?프로그램 청취 전에 추적 청취자가 과소 버퍼를 플러시하는지 확인하는 방법
소멸자를 사용하여 개체를 만듭니다. 소멸자를 비 웁니다. MSDN says 소멸자는 프로그램이 종료 될 때 호출됩니다. 나는 아직도 당신의 프로그램이 망가질 때 이것이 작동 할 것인지 알아 내려고 노력 중이다.
소멸자 일명 * 마무리 자 *는 적합하지 않습니다. 파이널 라이저에서 다른 일회용 객체 (예 :'DbConnection')는 이미 삭제되었거나 삭제되지 않을 수 있습니다. 종료자는 ** 관리되지 않는 ** 리소스 (예 : 임시 파일)를 정리하기위한 것입니다. 다른 것은 문제를 요구하고 있습니다. [처분 할 수있는 유형에 대한 Microsoft의 지침] (https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/dispose-pattern)을 참조하십시오. –
아니요, 쉬운 방법은 없습니다.
수동으로 버퍼를 플러시하는 메소드를 노출 할 수 있습니다. 특히 .NET 응용 프로그램이 처리되지 않은 예외로 인해 충돌 할 경우 AppDomain 핸들러를 등록 할 수 있습니다. 이 핸들러는 버퍼 플러시 메서드를 호출 할 수 있습니다.
그러나 일부 예외는 도메인에서 처리되지 않은 예외 처리기를 실행할 수도 있고 그렇지 않을 수도 있습니다. 저는 그들이 StackoverflowException, OutOfMemoryException 및 ThreadAbortedException이라고 생각합니다. 아마도 CLR 자체에만 해당되는 몇 가지 다른 유형 일 것입니다.
하지만 일반적으로 여기에 버퍼를 플러시하는 것이 좋습니다 AppDomain::UnhandledException.
의도적으로 응용 프로그램을 종료 할 때 버퍼를 플러시하지 않는다고 생각합니다.
FileOptions.WriteThrough. 아니, 그것은 우아하지 않다. [이 블로그 게시물] (http://blogs.msdn.com/b/vancem/archive/2012/08/13/windows-high-speed-logging-etw-in-c-net-using-system-diagnostics)을 확인하십시오. -tracing-eventsource.aspx) –