Nylig ble et prosjekt distribuert i et produksjonsmiljø, og det ble oppdaget at noen metoder kastet ut unormale meldinger
Imidlertid gis kun unormal feilinformasjon, og det finnes ikke noe unormalt linjenummer, bare at det er et problem med modellkonverteringen i en bestemt metode
Men la meg sammenligne dem én etter én, det er for irriterende, hvorfor ikke ta opp feil linjenummer?
log4net-loggkonfigurasjonen er som følger:
Jeg skrev bevisst en unntaksmelding i Home/Index-metoden på min lokale datamaskin for å se om linjenummeret ville bli registrert:
Jeg fant ut at feilloggfilen registrerer linjenummeret, noe som definitivt ikke er et problem med log4net-konfigurasjonen, fordi konfigurasjonen på begge sider er den samme
Kan det være et problem med kompilasjonsmodusen???
Min lokale datamaskin er i feilsøkingsmodus, og DLL-en som er kompilert av den offisielle serveren er i utgivelsesmodus
Deretter endret jeg det lokale prosjektet til utgivelsesmodus, og fant ut at det fortsatt var et linjenummer på posten.
Så, Baidu, første setning:Du må kopiere .pdb-filen som tilsvarer dll-filen”
Vel, er dette et problem? Deretter gikk jeg direkte til bin-katalogen, slettet .pdb-filen som tilhørte dll-en, og oppdaterte nettsiden, og fant unntaksloggen som følger:
Joda, det unormale linjenummeret blir ikke registrert!!!!
Er det virkelig et .pdb-problem!! Du må beholde .pdb-filen slik at linjenummeret blir registrert hvis det er unormalt!!
Hva er en PDB-fil til?
PDB-filer: Det enhver utvikler må vite
Hva er en PDB-fil?
De fleste utviklere bør vite at PDB-filer brukes til å hjelpe med feilsøking av programvare. Men hvordan han egentlig fungerer, er vi kanskje ikke kjent med. Denne artikkelen beskriver lagring og innhold i PDB-filer. Den beskriver også hvordan debuggeren finner PDB-filen som tilsvarer binay, og hvordan debuggeren finner kildekodefilen som tilsvarer binay. Denne artikkelen er for alle Native- og Managed-utviklere.
Før vi begynner, la oss definere to begreper: privat build, som brukes for å betegne en build generert på utviklerens egen maskin; offentlig build, som betyr en build generert på en offentlig build-maskin. privat bygging er relativt enkelt, fordi PDB og Binay er på samme sted, og vanligvis handler problemene vi har om offentlig bygging.
Det viktigste alle utviklere må vite, er at «PDB-filer er like viktige som kildekode», uten hvilken du ikke engang kan feilsøke. For offentlig build må symbolserveren lagre alle PDB-ene, og når brukeren rapporterer en feil, kan debuggeren automatisk finne den tilsvarende PDB-filen i binay, og både Visual Studio og Windbg vet hvordan de får tilgang til symbolserveren. Før du lagrer PDB og binay til symbolserveren, må du også kildeindeksere PDB-kjøringen, altså assosiere PDB og kilde.
Neste del forutsetter at Symbolserver- og Source Server-indekseringen allerede er satt opp. TFS2010 kan gjøres like enkelt som kildeindeksering og symbolserverkopiering for en ny build.
2. Innholdet i PDB-filen
PDB startet offisielt innholdet i PDB, og er ikke et offentlig tilgjengelig filformat, men Microsoft tilbyr et API for å hjelpe med å hente data fra PDB.
Den native C++ PDB-en inneholder følgende informasjon:
* offentlige, private og statiske funksjonsadresser;
* Navnet og adressen til den globale variabelen;
* Parameter- og lokale variabelnavn og forskyvninger på stakken;
* typedefinisjoner av klasse, struktur og data;
* Frame Pointer-utelatelsesdata for å traversere den native stakken på x86;
* Navnet og antall linjer i kildekodefilen;
.NET PDB-en inneholder kun to deler av informasjonen:
* Kildekodefilnavn og antall linjer;
* og navnet på den lokale variabelen;
* Alle andre data er allerede inkludert i . NET-metadata;
|
Publisert på 03.08.2017 14:13:01
|
|
|
|
