Recent, un proiect a fost implementat într-un mediu de producție și s-a descoperit că unele metode generau mesaje anormale
Totuși, se oferă doar informații anormale de eroare și nu există un număr anormal de linie, ci doar că există o problemă cu conversia modelului într-o anumită metodă
Dar lasă-mă să le compar pe rând, e prea enervant, de ce să nu înregistrezi numărul greșit al liniei?
Configurația log4net log este următoarea:
Am scris intenționat un mesaj de excepție în metoda Home/Index pe calculatorul meu local pentru a vedea dacă numărul liniei va fi înregistrat:
Am observat că fișierul de log de eroare înregistrează numărul liniei, ceea ce cu siguranță nu este o problemă cu configurația log4net, pentru că configurația pe ambele părți este aceeași
Ar putea fi o problemă cu modul de compilare???
Calculatorul meu local este în modul de depanare, iar DLL-ul compilat de serverul oficial este în modul de lansare
Apoi, am schimbat proiectul local în modul de lansare și am descoperit că era încă un număr de linie de record.
Apoi, Baidu, prima propoziție:Trebuie să copiezi fișierul .pdb corespunzător dull-ului”
Ei bine, e o problemă? Apoi, am mers direct la directorul bin, am șters fișierul .pdb corespunzător DLL-ului, apoi am reîmprospătat site-ul și am găsit jurnalul excepțiilor după cum urmează:
Într-adevăr, numărul anormal al liniei nu este înregistrat!!!!
Este chiar o problemă cu .pdb!! Trebuie să păstrezi fișierul .pdb astfel încât numărul liniei să fie înregistrat dacă este anormal!!
La ce folosește un fișier PDB?
Fișiere PDB: Ce trebuie să știe orice dezvoltator
Ce este un fișier PDB?
Majoritatea dezvoltatorilor ar trebui să știe că fișierele PDB sunt folosite pentru a ajuta la depanarea software-ului. Dar cum funcționează exact, poate nu suntem familiarizați. Acest articol descrie stocarea și conținutul fișierelor PDB. De asemenea, descrie cum depanatorul găsește fișierul PDB corespunzător lui binay și cum găsește fișierul cod sursă corespunzător lui binay. Acest articol este destinat tuturor dezvoltatorilor nativi și gestionați.
Înainte să începem, să definim doi termeni: build privată, care este folosită pentru a desemna o build generată pe propria mașină a dezvoltatorului; Public Build, ceea ce înseamnă o build generată pe o mașină publică. construcția privată este relativ simplă, pentru că PDB și binay sunt în același loc, iar de obicei problemele pe care le avem sunt legate de construcția publică.
Cel mai important lucru pe care toți dezvoltatorii trebuie să-l știe este că "fișierele PDB sunt la fel de importante ca codul sursă", fără de care nici măcar nu poți depana. Pentru compilarea publică, serverul de simboluri trebuie să stocheze toate PDB-urile, iar când utilizatorul raportează o eroare, depanatorul poate găsi automat fișierul PDB corespunzător în binay, iar atât Visual Studio cât și Windbg știu cum să acceseze serverul de simboluri. Înainte de a stoca PDB și binay în serverul de simboluri, trebuie să indexezi și rularea PDB, care este asocierea PDB cu sursa.
Partea următoare presupune că Simbolul Server și Indexarea Serverului Sursă sunt deja configurate. TFS2010 pot fi făcute la fel de simplu ca indexarea sursei și copierea serverului de simboluri pentru o versiune nouă.
2. Conținutul fișierului PDB
Începând oficial cu conținutul PDB, PDB nu este un format de fișier disponibil public, dar Microsoft oferă un API pentru a ajuta la obținerea datelor de la PDB.
PDB-ul nativ C++ conține următoarele informații:
* adrese de funcții publice, private și statice;
* Numele și adresa variabilei globale;
* Denumiri de parametri și variabile locale și deplasări pe stivă;
* definiții de tip ale clasei, structurii și datelor;
* Date de omisiune a pointerului cadrului pentru traversarea stivei native pe x86;
* Numele și numărul de linii din fișierul sursă;
PDB-ul .NET conține doar 2 părți de informație:
* Codul sursă, numele fișierului și numărul de linii;
* și numele variabilei locale;
* Toate celelalte date sunt deja incluse în . NET Metadata;
|
Postat pe 03.08.2017 14:13:01
|
|
|
|
