Libere a geração de arquivos .pdb, por quê?

Por que o Visual Studio 2005 gera os .pdbarquivos ao compilar na versão? Não deparei uma versão compilada, então por que eles são gerados?

Porque sem os arquivos PDB, seria impossível depurar uma compilação "Release" por algo que não seja a depuração no nível de endereço. As otimizações realmente fazem um número no seu código, tornando muito difícil encontrar o culpado se algo der errado (por exemplo, uma exceção é lançada). Mesmo definir pontos de interrupção é extremamente difícil, porque as linhas do código-fonte não podem ser comparadas individualmente com (ou mesmo na mesma ordem que) o código de montagem gerado. Os arquivos PDB ajudam você e o depurador, facilitando significativamente a depuração post-mortem.

Você defende que, se o seu software estiver pronto para o lançamento, você deverá ter feito toda a sua depuração até então. Embora isso certamente seja verdade, há alguns pontos importantes a serem lembrados:

1. Você também deve testar e depurar seu aplicativo (antes de liberá-lo) usando a compilação "Release". Isso ocorre porque ativar as otimizações (elas são desativadas por padrão na configuração "Debug") às vezes pode causar erros sutis que você não conseguiria capturar. Ao fazer essa depuração, você desejará os símbolos do PDB.

2. Os clientes frequentemente relatam casos extremos e erros que surgem apenas em condições "ideais". São coisas quase impossíveis de reproduzir no laboratório, porque elas dependem de alguma configuração esquisita da máquina desse usuário. Se forem clientes particularmente úteis, eles reportarão a exceção lançada e fornecerão um rastreamento de pilha. Ou eles ainda permitem que você empreste sua máquina para depurar seu software remotamente. Em qualquer um desses casos, você desejará que os arquivos PDB o ajudem.

3. A criação de perfil sempre deve ser feita nas compilações "Release" com as otimizações ativadas. E mais uma vez, os arquivos PDB são úteis, pois permitem que as instruções de montagem que estão sendo perfiladas sejam mapeadas de volta ao código-fonte que você realmente escreveu.

Você não pode voltar e gerar os arquivos PDB após a compilação. ^* Se você não criá-los durante a compilação, perdeu a oportunidade. Não dói nada para criá-los. Se você não deseja distribuí-los, pode simplesmente omiti-los dos seus binários. Mas se você decidir mais tarde que deseja, não terá sorte. Melhor sempre gerá-los e arquivar uma cópia, caso você precise deles.

Se você realmente deseja desativá-los, é sempre uma opção. Na janela Propriedades do seu projeto, defina a opção "Informações de depuração" como "nenhuma" para qualquer configuração que você queira alterar.

Observe, no entanto, que as configurações de "depuração" e "Lançamento" fazer pelo uso padrão configurações diferentes para a emissão de informações de depuração. Você deseja manter essa configuração. A opção "Informações de depuração" está definida como "cheia" para uma compilação de depuração, o que significa que, além de um arquivo PDB, as informações do símbolo de depuração são incorporadas ao assembly. Você também recebe símbolos que suportam recursos interessantes, como editar e continuar. No modo Release, a opção "pdb-only" está selecionada, o que, como parece, inclui apenas o arquivo PDB, sem afetar o conteúdo do assembly. Portanto, não é tão simples quanto a mera presença ou ausência de arquivos PDB no seu /bindiretório. Mas, supondo que você use a opção "pdb-only", o arquivo PDB '

_{^* Como Marc Sherman aponta em um comentário , desde que seu código-fonte não tenha sido alterado (ou você pode recuperar o código original de um sistema de controle de versão), você pode reconstruí-lo e gerar um arquivo PDB correspondente. Pelo menos, geralmente. Isso funciona bem na maioria das vezes, mas não é garantido que o compilador gere binários idênticos sempre que você compilar o mesmo código , portanto, pode haver diferenças sutis. Pior, se você fez alguma atualização no seu conjunto de ferramentas nesse meio tempo (como a aplicação de um service pack para o Visual Studio), é mais provável que os PDBs correspondam. Para garantir a geração confiável de ex postfactoArquivos PDB, você precisaria arquivar não apenas o código-fonte em seu sistema de controle de versão, mas também os binários de toda a cadeia de ferramentas de construção para garantir que você pudesse recriar com precisão a configuração do seu ambiente de construção. Escusado será dizer que é muito mais fácil simplesmente criar e arquivar os arquivos PDB.}

O PDB pode ser gerado Releasetanto quanto para Debug. Isso é definido em (no VS2010, mas no VS2005 deve ser semelhante):

Projeto → Propriedades → Compilar → Avançado → Informações sobre depuração

Apenas mude para None.

Sem os arquivos .pdb, é praticamente impossível passar pelo código de produção; você precisa confiar em outras ferramentas que podem ser caras e demoradas. Entendo que você pode usar rastreamento ou windbg, por exemplo, mas isso realmente depende do que você deseja alcançar. Em certos cenários, você apenas deseja percorrer o código remoto (sem erros ou exceções) usando os dados de produção para observar um comportamento específico, e é aí que os arquivos .pdb são úteis. Sem eles, executar o depurador nesse código é impossível.

Por que você tem tanta certeza de que não irá depurar as versões de lançamento? Às vezes (espero que raramente aconteça), você pode obter um relatório de defeito de um cliente que não é reproduzível na versão de depuração por algum motivo (horários diferentes, comportamento pequeno e diferente ou o que for). Se esse problema parecer reproduzível na versão, você ficará feliz em ter o pdb correspondente.

Além disso, você pode utilizar despejos de memória para depurar seu software. O cliente envia para você e, em seguida, você pode usá-lo para identificar a versão exata da sua fonte - e o Visual Studio puxa o conjunto certo de símbolos de depuração (e a fonte, se você estiver configurado corretamente) usando o despejo de memória. Consulte a documentação da Microsoft em Symbol Stores .

Arquivo .PDB é o nome abreviado de "Banco de Dados do Programa". Ele contém as informações sobre o ponto de depuração do depurador e os recursos usados ​​ou de referência. É gerado quando construímos como modo de depuração. Sua aplicação permite depurar em tempo de execução.

O tamanho é o aumento do arquivo .PDB no modo de depuração. É usado quando estamos testando nosso aplicativo.

Bom artigo do arquivo pdb.

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

Em uma solução de vários projetos, geralmente você deseja ter uma configuração que não gera nenhum arquivo PDB ou XML. Em vez de alterar a Debug Infopropriedade de cada projeto none, pensei que seria mais conveniente adicionar um evento pós-compilação que funcionasse apenas em uma configuração específica.

Infelizmente, o Visual Studio não permite que você especifique diferentes eventos pós-compilação para diferentes configurações. Então, decidi fazer isso manualmente, editando o csprojarquivo do projeto de inicialização e adicionando o seguinte (em vez de qualquer PostBuildEventtag existente ):

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

Infelizmente, isso deixará a caixa de texto do evento pós-compilação em branco e colocar qualquer coisa nela poderá ter resultados imprevisíveis.

Os símbolos de depuração ( .pdb) e os arquivos XML doc ( .xml) representam uma grande porcentagem do tamanho total e não devem fazer parte do pacote de implantação regular. Mas deve ser possível acessá-los caso sejam necessários.

Uma abordagem possível: no final do processo de construção do TFS, mova-os para um artefato separado.

Na verdade, sem os arquivos PDB e as informações simbólicas existentes, seria impossível criar um relatório de falha bem-sucedido (arquivos de despejo de memória) e a Microsoft não teria uma imagem completa do que causou o problema.

E assim, ter o PDB melhora os relatórios de falhas.