디버그 정보가 "전체"또는 "pdb 전용"인 릴리스 빌드를 컴파일해야합니까?

C # 프로젝트 용 Visual Studio 2010에서 프로젝트 속성> 빌드> 고급> 디버그 정보로 이동하면 없음, 전체 또는 pdb 전용의 세 가지 옵션이 있습니다. 이 질문 에 대한 답변을 바탕으로 전체 및 pdb 전용의 차이점을 이해한다고 생각합니다. 그러나 릴리스 빌드에 더 적합한 것은 무엇입니까? "전체"를 사용하면 성능에 영향이 있습니까? "pdb 전용"을 사용하면 프로덕션 문제를 디버깅하기가 더 어렵습니까?

"full"과 "pdbonly"의 차이점은 무엇입니까? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/debug-compiler-option

나는 pdb-only. 출시 된 제품에 디버거를 연결할 수 없지만 크래시 덤프가 발생하면 Visual Studio 또는 WinDBG 를 사용하여 크래시 발생시 스택 추적 및 메모리 덤프를 검사 할 수 있습니다 .

당신이가는 경우 full가 아니라 pdb-only, 당신은 실행 파일이 디버거에 직접 부착 될 수 있다는 것을 제외하고는 동일한 혜택을받을 수 있습니다. 제품 및 고객을 고려할 때 이것이 합리적인지 판단해야합니다.

충돌 보고서가 올 때 참조 할 수 있도록 PDB 파일을 어딘가에 저장해야합니다. 이러한 디버깅 기호를 저장 하도록 기호 서버 를 설정할 수 있다면 훨씬 좋습니다.

를 사용하여 빌드하기로 선택 none하면 현장에서 충돌이 발생했을 때 의지 할 수 없습니다. 충돌에 대한 사후 조사를 수행 할 수 없으므로 문제를 추적하는 능력이 심각하게 저하 될 수 있습니다.

성능에 대한 참고 사항 :

모두 존 로빈스 와 에릭 Lippert의는 [정보] 블로그 게시물을 작성했습니다 /debug플래그, 그들은 모두 나타냅니다 이 설정이 제로 성능에 미치는 영향을 . /optimize컴파일러가 최적화를 수행해야하는지 여부를 나타내는 별도의 플래그가 있습니다.

경고 / debug 스위치에 대한 MSDN 설명서 (Visual Studio에서는 디버그 정보 임)가 오래된 것 같습니다! 이것은 잘못된 것입니다.

/ debug : full 을 사용 하는 경우 JIT 최적화 코드의 속도와 크기에 약간의 영향을 미치고 / debug : full을 사용하면 코드 품질에 약간의 영향이 있음을 유의하십시오 . 릴리스 코드 생성을 위해 / debug : pdbonly 또는 PDB 없음을 권장 합니다.

/ debug : pdbonly 와 / debug : full의 한 가지 차이점은 / debug : full을 사용하면 컴파일러가를 내보내고 DebuggableAttributeJIT 컴파일러에 디버그 정보를 사용할 수 있음을 알리는 데 사용된다는 것입니다.

그렇다면 이제 무엇이 사실입니까?

1. Pdb 전용 – .NET 2.0 이전에는 출시 된 제품 (고객 컴퓨터)의 크래시 덤프를 조사하는 데 도움이되었습니다. 그러나 디버거를 연결할 수 없었습니다. .NET 2.0에서는 그렇지 않습니다. 그것은는 정확히 같은 전체 .
2. Full – 크래시 덤프를 조사하는 데 도움이되며 릴리스 빌드에 디버거를 연결할 수도 있습니다. 그러나 MSDN에서 언급 한 것과 달리 .NET 2.0부터는 성능에 영향을주지 않습니다. Pdb-only 와 정확히 동일 합니다 .

정확히 동일하다면 왜 이러한 옵션이 있습니까? John Robbins (윈도우 디버깅 신) 는 역사적 이유 때문에 이것들이 있다는 것을 알아 냈습니다 .

.NET 1.0에서는 차이가 있었지만 .NET 2.0에서는 그렇지 않습니다. .NET 4.0이 동일한 패턴을 따르는 것 같습니다. CLR 디버깅 팀과 다시 한 번 확인한 후에는 전혀 차이가 없습니다.

JITter가 디버그 빌드를 수행하는지 여부를 제어하는 ​​것은 / optimize 스위치입니다. <…>

결론은 / optimize + 및 / debug 스위치를 사용하여 릴리스 빌드를 빌드하여 소스 코드로 디버깅 할 수 있도록한다는 것입니다.

그런 다음 그는 그것을 증명하기 위해 계속합니다.

이제 최적화는 별도의 스위치의 일부입니다 /optimize(Visual Studio에서는라고 함 Optimize code).

간단히 말해, DebugInfo 설정 pdb-only 또는 full에 관계없이 동일한 결과를 얻을 수 있습니다. 권장 사항은 출시 된 제품에서 크래시 덤프를 분석하거나 디버거를 연결하지 못하므로 None 을 피하는 것입니다.

PDB 만 필요하지만 사용자에게 PDB 파일을 제공하고 싶지는 않습니다. 그러나 바이너리와 함께 직접 사용하면 WinDbg와 같은 디버거에 크래시 덤프를로드하고 프로그램이 실제로 실패한 위치를 확인할 수 있습니다. 액세스 권한이없는 시스템에서 코드가 충돌 할 때 유용 할 수 있습니다.

전체 디버그는 코드에 [Debuggable] 속성을 추가합니다. 이것은 속도에 큰 영향을 미칩니다. 예를 들어, 단일 단계를보다 쉽게 ​​수행하기 위해 일부 루프 최적화를 비활성화 할 수 있습니다. 또한 추적 기능을 사용하므로 JIT 프로세스에 약간의 영향을 미칩니다.

처리되지 않은 예외 처리기를 작성하는 중이며 pdb-only를 사용할 때 스택 추적에 줄 번호가 포함됩니다. 그렇지 않으면 없음을 선택하면 하위 / 함수 이름이 표시됩니다.

.pdb를 배포하지 않으면 pdb 전용 빌드를 사용해도 스택 추적에서 줄 번호를 얻지 못합니다.

그래서 저는 VB 앱의 exe와 함께 pdb를 배포합니다 (LAN에 XCOPY 배포).