왜 .pdb 파일 생성을 해제합니까?

.pdb릴리스에서 컴파일 할 때 Visual Studio 2005가 파일을 생성하는 이유는 무엇 입니까? 릴리스 빌드를 디버깅하지 않으므로 왜 생성됩니까?

PDB 파일이 없으면 주소 수준 디버깅 이외의 다른 방법으로 "릴리스"빌드를 디버깅 할 수 없습니다. 최적화는 실제로 코드에서 숫자를 수행하므로 문제가 발생하면 (예 : 예외 발생) 범인을 찾기가 매우 어렵습니다. 소스 코드 행을 생성 된 어셈블리 코드와 일대일로 (또는 동일한 순서로) 일치시킬 수 없기 때문에 중단 점 설정조차 매우 어렵습니다. PDB 파일은 사후 디버깅을 훨씬 쉽게 만들어 사용자와 디버거를 도와줍니다.

소프트웨어를 출시 할 준비가 되었으면 그때까지 모든 디버깅을 수행했음을 지적합니다. 확실히 사실이지만 명심해야 할 몇 가지 중요한 사항이 있습니다.

1. 당신은해야 또한 테스트하고 "릴리스"빌드를 사용하여 응용 프로그램을 (당신이 그것을 해제하기 전에) 디버깅합니다. 최적화를 켜면 (디버그 구성에서 기본적으로 비활성화되어 있음) 때로는 잡을 수없는 미묘한 버그가 나타날 수 있기 때문입니다. 이 디버깅을 수행 할 때 PDB 기호가 필요합니다.

2. 고객은 종종 "이상적인"조건에서만 자라는 최첨단 사례 및 버그를보고합니다. 이것들은 실험실에서 재현하기가 거의 불가능한데, 그 이유는 사용자 컴퓨터의 일부 구성에 의존하기 때문입니다. 고객이 특히 도움이되는 경우, 발생한 예외를보고하고 스택 추적을 제공합니다. 또는 컴퓨터를 빌려서 소프트웨어를 원격으로 디버깅 할 수도 있습니다. 두 경우 모두 PDB 파일이 도움이 될 것입니다.

3. 프로파일 링은 항상 최적화가 활성화 된 "릴리스"빌드에서 수행 해야합니다 . 그리고 다시 한 번, PDB 파일은 프로파일 링중인 어셈블리 명령어를 실제로 작성한 소스 코드에 다시 매핑 할 수 있기 때문에 편리합니다.

컴파일 후 되돌아 와서 PDB 파일 을 생성 할 수 없습니다 . ^* 빌드 중에 생성하지 않으면 기회를 잃어버린 것입니다. 그것들을 만들기 위해 아무것도 아프지 않습니다. 배포하지 않으려면 바이너리에서 간단히 생략하면됩니다. 그러나 나중에 원하는 것을 결정하면 운이 나빠집니다. 필요할 때를 대비하여 항상 생성하고 사본을 보관하는 것이 좋습니다.

당신이 정말로 그들을 끄고 싶다면, 그것은 항상 옵션입니다. 프로젝트의 속성 창에서 변경하려는 구성에 대해 "디버그 정보"옵션을 "없음"으로 설정하십시오.

그러나 "디버그"및 "릴리스"구성 은 기본적으로 디버그 정보를 생성하기 위해 다른 설정을 사용합니다. 이 설정을 유지하고 싶을 것입니다. 디버그 빌드의 경우 "디버그 정보"옵션이 "전체"로 설정됩니다. 즉, PDB 파일 외에도 디버깅 심볼 정보가 어셈블리에 포함됩니다. 편집 및 계속과 같은 멋진 기능을 지원하는 심볼도 있습니다. 릴리스 모드에서는 "pdb-only"옵션이 선택되는데, 소리와 마찬가지로 어셈블리의 내용에 영향을주지 않고 PDB 파일 만 포함합니다. 따라서 /bin디렉토리 에 PDB 파일의 존재 유무만큼 간단하지 않습니다 . 그러나 "pdb-only"옵션을 사용한다고 가정하면 PDB 파일은

_{^* 로 마크 셔먼이 코멘트에 지적 소스 코드가 변경되지 않은 (또는 버전 관리 시스템에서 원본 코드를 검색 할 수 있습니다)만큼, 당신은 그것을 다시와 일치하는 PDB 파일을 생성 할 수 있습니다. 적어도 보통은 이것은 대부분 잘 작동하지만 컴파일러는 동일한 코드를 컴파일 할 때마다 동일한 바이너리를 생성한다고 보장하지 않으므로 미묘한 차이 가있을 수 있습니다. 최악의 경우 (Visual Studio 용 서비스 팩 적용과 같이) 툴체인을 업그레이드 한 경우 PDB가 일치 할 가능성이 훨씬 줄어 듭니다. 출고 후 신뢰할 수있는 생성 보장PDB 파일을 사용하려면 빌드 환경의 구성을 정확하게 다시 만들 수 있도록 버전 제어 시스템의 소스 코드뿐만 아니라 전체 빌드 툴체인의 바이너리도 보관해야합니다. PDB 파일을 간단히 생성하고 보관하는 것이 훨씬 쉽다는 것은 말할 나위도 없습니다.}

를 위해 Release뿐만 아니라 PDB를 생성 할 수 있습니다 Debug. 이것은 VS2010에서 설정되었지만 VS2005에서는 유사해야합니다.

프로젝트 → 속성 → 빌드 → 고급 → 디버그 정보

로 변경하십시오 None.

.pdb 파일이 없으면 프로덕션 코드를 단계별로 실행하는 것이 사실상 불가능합니다. 많은 비용과 시간이 소요될 수있는 다른 도구를 사용해야합니다. 예를 들어 추적 또는 windbg를 사용할 수 있지만 실제로 달성하려는 대상에 따라 다릅니다. 특정 시나리오에서는 특정 동작을 관찰하기 위해 프로덕션 데이터를 사용하여 원격 코드 (오류 또는 예외 없음)를 단계별로 실행하려고하는데,이 위치에서 .pdb 파일이 편리합니다. 그들 없이는 해당 코드에서 디버거를 실행할 수 없습니다.

릴리스 빌드를 디버그하지 않는 이유가 무엇입니까? 간혹 (아주 드물지만 발생) 고객이 디버그 버전에서 재현 할 수없는 결함 보고서 (다른 타이밍, 작은 다른 동작 등)가 발생할 수 있습니다. 릴리스 빌드에서 해당 문제를 재현 할 수있는 것으로 보이면 pdb와 일치하게되어 기쁩니다.

또한 크래시 덤프를 사용하여 소프트웨어를 디버깅 할 수 있습니다. 고객은 고객에게이를 전송 한 다음이를 사용하여 소스의 정확한 버전을 식별 할 수 있으며 Visual Studio는 크래시 덤프를 사용하여 올바른 디버깅 심볼 세트 (및 올바르게 설정 한 경우 소스)를 가져옵니다. Symbol Stores에 대한 Microsoft 설명서를 참조하십시오 .

.PDB 파일은 "Program Database"의 짧은 이름입니다. 디버거의 디버그 지점 및 사용되거나 참조되는 리소스에 대한 정보가 들어 있습니다. 디버그 모드로 빌드 할 때 생성됩니다. 런타임에 응용 프로그램을 디버깅 할 수 있습니다.

크기는 디버그 모드에서 .PDB 파일의 크기입니다. 애플리케이션을 테스트 할 때 사용됩니다.

pdb 파일의 좋은 기사.

http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P

다중 프로젝트 솔루션에서는 일반적으로 PDB 또는 XML 파일을 전혀 생성하지 않는 하나의 구성이 필요합니다. Debug Info모든 프로젝트 의 속성을 로 변경하는 대신 none특정 구성에서만 작동하는 빌드 후 이벤트를 추가하는 것이 더 편리하다고 생각했습니다.

불행히도 Visual Studio에서는 다른 구성에 대해 다른 빌드 후 이벤트를 지정할 수 없습니다. 따라서 csproj시작 프로젝트 파일을 편집하고 기존 PostBuildEvent태그 대신 다음을 추가하여 수동 으로이 작업을 수행하기로 결정했습니다 .

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

불행히도, 이것은 빌드 후 이벤트 텍스트 상자를 비워두고 그 안에 아무것도 넣지 않으면 예기치 않은 결과가 발생할 수 있습니다.

디버그 기호 ( .pdb) 및 XML doc ( .xml) 파일은 전체 크기의 큰 비율을 구성하며 일반 배포 패키지의 일부가되어서는 안됩니다. 그러나 필요한 경우 액세스 할 수 있어야합니다.

한 가지 가능한 접근 방식 : TFS 빌드 프로세스가 끝나면 별도의 아티팩트로 이동하십시오.

실제로 PDB 파일과 기호 정보가 없으면 성공적인 충돌 보고서 (메모리 덤프 파일)를 만들 수 없으며 Microsoft는 문제의 원인을 완전히 파악할 수 없습니다.

따라서 PDB를 사용하면 충돌보고 기능이 향상됩니다.