Nyligen implementerades ett projekt i en produktionsmiljö och det upptäcktes att vissa metoder kastade ut avvikande meddelanden
Dock ges endast onormal felinformation, och det finns inget onormalt radnummer, bara att det finns ett problem med modellkonverteringen i en viss metod
Men låt mig jämföra dem en efter en, det är för irriterande, varför inte spela in fel linjenummer?
Log4net-loggkonfigurationen är följande:
Jag skrev medvetet ett undantagsmeddelande i Home/Index-metoden på min lokala dator för att se om radnumret skulle registreras:
Jag upptäckte att felloggfilen registrerar radnumret, vilket definitivt inte är ett problem med log4net-konfigurationen, eftersom konfigurationen på båda sidor är densamma
Kan det vara ett problem med kompileringsläget???
Min lokala dator är i felsökningsläge, och DLL:n som kompileras av den officiella servern är i releaseläge
Sedan ändrade jag det lokala projektet till releaseläge och upptäckte att det fortfarande var ett radnummer för posten.
Sedan, Baidu, första meningen:Du behöver kopiera .pdb-filen som motsvarar dll:n”
Är det här ett problem? Sedan gick jag direkt till bin-katalogen, raderade .pdb-filen som motsvarade dll:n, och uppdaterade sedan webbplatsen, och hittade undantagsloggen enligt följande:
Mycket riktigt registreras inte det onormala radnumret!!!!
Är det verkligen ett .pdb-problem!! Du måste behålla .pdb-filen så att radnumret registreras om det är onormalt!!
Vad är en PDB-fil till för?
PDB-filer: Vad varje utvecklare måste veta
Vad är en PDB-fil?
De flesta utvecklare bör veta att PDB-filer används för att hjälpa till med felsökning av mjukvara. Men hur han exakt fungerar kanske vi inte är bekanta med. Denna artikel beskriver lagringen och innehållet i PDB-filer. Den beskriver också hur felsökaren hittar PDB-filen som motsvarar binay och hur felsökaren hittar källkodsfilen som motsvarar binay. Den här artikeln är för alla Native- och Managed-utvecklare.
Innan vi börjar, låt oss definiera två termer: privat build, som används för att beteckna en build genererad på utvecklarens egen maskin; offentlig build, vilket betyder en build genererad på en offentlig build-maskin. privat byggnation är relativt enkel, eftersom PDB och Binay är på samma plats, och vanligtvis handlar problemen vi har om offentlig byggnation.
Det viktigaste som alla utvecklare behöver veta är att "PDB-filer är lika viktiga som källkod", utan vilka du inte ens kan felsöka. För publik build måste symbolservern lagra alla PDB:er, och när användaren rapporterar ett fel kan felsökaren automatiskt hitta motsvarande PDB-fil i binay, och både Visual Studio och Windbg vet hur man får tillgång till symbolservern. Innan du lagrar PDB och binay till symbolservern behöver du också source indexera PDB-körningen, vilket innebär att associera PDB och source.
Nästa del förutsätter att Symbolserver- och Source Server-indexeringen redan är uppsatta. TFS2010 kan göras lika enkelt som källkodsindexering och symbolserverkopiering för en ny build.
2. Innehållet i PDB-filen
Officiellt startade PDB:s innehåll och PDB är inte ett offentligt tillgängligt filformat, men Microsoft tillhandahåller ett API för att hjälpa till att hämta data från PDB.
Den inbyggda C++ PDB:n innehåller följande information:
* offentliga, privata och statiska funktionsadresser;
* Namnet och adressen till den globala variabeln;
* Parameter- och lokala variabelnamn samt offsets på stacken;
* typdefinitioner av klass, struktur och data;
* Frame Pointer Utelämnande data för att traversera den inbyggda stacken på x86;
* Namnet och antalet rader i källkodsfilen;
.NET PDB innehåller endast två delar av informationen:
* Källkodsfilnamn och antal rader;
* och namnet på den lokala variabeln;
* All annan data ingår redan i . NET-metadata;
|
Publicerad på 2017-08-03 14:13:01
|
|
|
|
