Nemrégiben egy projektet telepítettek egy gyártási környezetben, és kiderült, hogy egyes módszerek rendelő üzeneteket bocsátanak ki
Azonban csak rendellenes hibainformációt adnak meg, nincs rendellenes sorszám, csak az, hogy probléma van a modellátalakítással egy adott módszernél
De hadd hasonlítsam össze őket egyenként, túl idegesítő, miért ne írnánk fel rossz sorszámot?
A log4net naplókonfigurációja a következő:
Szándékosan írtam egy kivétel üzenetet a Home/Index módszerben a helyi számítógépen, hogy megnézzem, rögzítik-e a sorszámot:
Azt tapasztaltam, hogy a hibanapló fájl rögzíti a sorszámot, ami biztosan nem probléma a log4net konfigurációval, mert mindkét oldalon ugyanaz a konfiguráció
Lehet, hogy a fordítási móddal van gond???
A helyi számítógépem hibakeresési módban van, és a hivatalos szerver által fordított DLL kiadási módban van
Ezután átváltottam a helyi projektet kiadás módra, és azt tapasztaltam, hogy még mindig egy lemezsorszám volt.
Aztán Baidu, az első mondat:Le kell másolnod a .pdb fájlt, amely a dll-hez tartozik”
Nos, ez gond? Ezután közvetlenül a bin könyvtárba mentem, töröltem a dll-hez tartozó .pdb fájlt, majd frissítettem a weboldalt, és megtaláltam a következő kivételnaplót:
Valóban, a rendellenes sorszám nem kerül rögzítésre!!!!
Tényleg .pdb probléma ez!! Meg kell tartanod a .pdb fájlt, hogy a sorszám feljegyezve legyen, ha rendellenes!!
Mire való a PDB fájl?
PDB fájlok: Amit minden fejlesztőnek tudnia kell
Mi az a PDB fájl?
A legtöbb fejlesztőnek tudnia kell, hogy a PDB fájlokat a szoftveres hibakeresés segítésére használják. De pontosan hogyan működik, azt talán nem ismerjük. Ez a cikk a PDB fájlok tárolását és tartalmát írja le. Azt is leírja, hogyan találja meg a hibakereső a binay-hoz tartozó PDB fájlt, és hogyan találja meg a biny-hez tartozó forráskódfájlt. Ez a cikk minden natív és menedzselt fejlesztőnek szól.
Mielőtt elkezdenénk, definiáljunk két fogalmat: privát build, amely a fejlesztő saját gépén generált buildet jelöl; A nyilvános build, ami egy nyilvános gépen generált build buildet jelent. A magán építés viszonylag egyszerű, mert a PDB és a binay ugyanott van, és általában a nyilvános építéssel kapcsolatos problémák jelentkeznek.
A legfontosabb, amit minden fejlesztőnek tudnia kell, hogy "a PDB fájlok ugyanolyan fontosak, mint a forráskód", amelyek nélkül még hibakeresést sem lehet elérni. Nyilvános építésnél a szimbólumszervernek tárolnia kell az összes PDB-t, és amikor a felhasználó hibát jelent, a hibakereső automatikusan megtalálja a megfelelő PDB fájlt binayben, és mind a Visual Studio, mind a Windbg tudja, hogyan lehet hozzáférni a szimbólumszerverhez. Mielőtt a PDB és a binay szimbólumszerverre tárolná, a PDB futtatását is forrásindexelni kell, ami a PDB és a forrás összekapcsolása.
A következő rész feltételezi, hogy a Szimbólumszerver és a Forrásszerver Indexelés már be van állítva. TFS2010 egyszerűen elérhető a forrásindexeléssel és a szimbólumszerver másolásával egy új buildhez.
2. A PDB fájl tartalma
Hivatalosan is elindítva a PDB tartalmát, a PDB nem nyilvánosan elérhető fájlformátum, de a Microsoft API-t biztosít, amely segít adatokat szerezni a PDB-ről.
A natív C++ PDB a következő információkat tartalmazza:
* nyilvános, privát és statikus funkciós címek;
* A globális változó neve és címe;
* Paraméter- és helyi változónevek és eloszlatások a veremen;
* osztály, struktúra és adatok típusmeghatározása;
* Frame Pointer kihagyási adatok a natív stack áthaladásához x86-on;
* A forráskód fájl neve és sorszáma;
A .NET PDB csak két információs részt tartalmaz:
* Forráskódfájl neve és sorszám;
* és a helyi változó neve;
* Minden egyéb adat már szerepel a . NET metaadat;
|
Közzétéve 2017. 08. 03. 14:13:01
|
|
|
|
