Recentemente, um projeto foi implantado em um ambiente de produção e foi descoberto que alguns métodos emitiam mensagens anômalas
No entanto, apenas informações anormais de erro são fornecidas, e não há número de linha anormal, apenas que há um problema com a conversão do modelo em determinado método
Mas deixa eu comparar um por um, é muito chato, por que não registrar o número errado da linha?
A configuração do log4net é a seguinte:
Deliberadamente escrevi uma mensagem de exceção no método Home/Index no meu computador local para ver se o número da linha seria registrado:
Percebi que o arquivo de log de erro registra o número da linha, o que definitivamente não é um problema na configuração do log4net, porque a configuração dos dois lados é a mesma
Será que pode ser um problema com o modo de compilação???
Meu computador local está no modo de depuração, e a DLL compilada pelo servidor oficial está em modo de lançamento
Depois, mudei o projeto local para o modo de lançamento e descobri que ainda era um número de linha de registro.
Então, Baidu, a primeira frase:Você precisa copiar o arquivo .pdb correspondente ao dll”
Bem, isso é um problema? Depois, fui direto ao diretório bin, deletei o arquivo .pdb correspondente à DLL, atualizei o site e encontrei o registro de exceções da seguinte forma:
De fato, o número anormal da linha não é registrado!!!!
Será que é realmente um problema .pdb!! Você precisa manter o arquivo .pdb para que o número da linha seja registrado caso seja anormal!!
Para que serve um arquivo PDB?
Arquivos PDB: O que todo desenvolvedor deve saber
O que é um arquivo PDB?
A maioria dos desenvolvedores deve saber que arquivos PDB são usados para ajudar na depuração de software. Mas como exatamente ele trabalha, talvez não estejamos familiarizados. Este artigo descreve o armazenamento e o conteúdo dos arquivos PDB. Também descreve como o depurador encontra o arquivo PDB correspondente a binay e como o depurador encontra o arquivo de código-fonte correspondente a binay. Este artigo é para todos os desenvolvedores Nativos e Gerenciados.
Antes de começarmos, vamos definir dois termos: build privada, que é usado para denotar uma build gerada na própria máquina do desenvolvedor; Build pública, que significa uma build gerada em uma máquina de build pública. a construção privada é relativamente simples, porque PDB e binay ficam no mesmo lugar, e geralmente os problemas que temos são relacionados à construção pública.
A coisa mais importante que todos os desenvolvedores precisam saber é que "arquivos PDB são tão importantes quanto o código-fonte", sem o qual você nem consegue depurar. Para compilações públicas, o servidor de símbolos precisa armazenar todos os PDBs e, quando o usuário reporta um erro, o depurador pode automaticamente encontrar o arquivo PDB correspondente em binay, e tanto o Visual Studio quanto o Windbg sabem como acessar o servidor de símbolos. Antes de armazenar PDB e binay no servidor de símbolos, você também precisa indexar a run do PDB, que é associar PDB e source.
A próxima parte assume que o Servidor de Símbolos e a Indexação do Servidor de Origem já estão configurados. TFS2010 pode ser feito tão simples quanto indexação de origem e cópia de servidor de símbolos para uma nova build.
2. O conteúdo do arquivo PDB
Oficialmente iniciando o conteúdo do PDB, o PDB não é um formato de arquivo disponível publicamente, mas a Microsoft fornece uma API para ajudar a obter dados do PDB.
O PDB nativo em C++ contém as seguintes informações:
* endereços públicos, privados e de função estática;
* O nome e endereço da variável global;
* Nomes e deslocamentos de parâmetros e variáveis locais na pilha;
* definições de tipo de classe, estrutura e dados;
* Omissão de Frame Pointer dados para atravessar a pilha nativa em x86;
* O nome e o número de linhas no arquivo de código-fonte;
O .NET PDB contém apenas 2 partes de informação:
* Código-fonte nome do arquivo e número de linhas;
* e o nome da variável local;
* Todos os outros dados já estão incluídos no . NET Metadata;
|
Publicado em 03/08/2017 14:13:01
|
|
|
|
