Нещодавно проєкт був розгорнутий у виробничому середовищі, і було виявлено, що деякі методи викидають аномальні повідомлення
Однак надається лише інформація про аномальну помилку, і немає аномального номера рядка, лише є проблема з конвертацією моделі певним методом
Але дозвольте порівняти їх по одному, це надто дратує, чому б не записати неправильний номер рядка?
Конфігурація log4net log виглядає так:
Я навмисно написав повідомлення про виключення у методі Home/Index на своєму локальному комп'ютері, щоб перевірити, чи буде записано номер рядка:
Я помітив, що файл журналу помилок записує номер рядка, що точно не є проблемою з конфігурацією log4net, бо конфігурація з обох сторін однакова
Чи може бути проблема в режимі компіляції???
Мій локальний комп'ютер у режимі налагодження, а DLL, скомпільована офіційним сервером, у режимі релізу
Потім я змінив локальний проєкт на режим релізу і виявив, що це все ще номер рядка запису.
Потім, Байду, перше речення:Вам потрібно скопіювати .pdb-файл, що відповідає dll”
Ну, це проблема? Потім я одразу зайшов у папку bin, видалив .pdb-файл, що відповідав dll, оновив сайт і знайшов журнал винятків так:
І справді, аномальний номер лінії не фіксується!!!!
Це справді проблема з .pdb!! Потрібно зберігати .pdb-файл, щоб номер рядка був зафіксований, якщо він аномальний!!
Для чого потрібен PDB-файл?
PDB-файли: Що повинен знати кожен розробник
Що таке PDB-файл?
Більшість розробників повинні знати, що PDB-файли використовуються для допомоги у програмному налагодженні. Але як саме він працює, можливо, нам не знайомо. У цій статті описується зберігання та вміст файлів PDB. Він також описує, як відлагоджувач знаходить PDB-файл, що відповідає binay, і як він знаходить файл вихідного коду, що відповідає binay. Ця стаття для всіх нативних і керованих розробників.
Перш ніж почати, давайте визначимо два терміни: приватна збірка, яка використовується для позначення збірки, створеної на власній машині розробника; Публічна збірка, тобто збірка, згенерована на машині публічної збірки. приватне будівництво відносно просте, бо PDB і Binay знаходяться в одному місці, і зазвичай проблеми стосуються публічного будівництва.
Найважливіше, що потрібно знати всім розробникам — це те, що «PDB-файли так само важливі, як і вихідний код», без яких ви навіть не можете налагодити. Для публічної збірки сервер символів має зберігати всі PDB, а коли користувач повідомляє про помилку, відлагоджувач автоматично може знайти відповідний PDB-файл у binay, і Visual Studio та Windbg знають, як отримати доступ до сервера символів. Перед тим, як зберігати PDB і binay на сервері символів, потрібно також індексувати PDB запуск, тобто асоціювати PDB і джерело.
Наступна частина передбачає, що Symbol Server і Source Server Indexing вже налаштовані. TFS2010 можна зробити так само просто, як індексація вихідного коду та копіювання символічного сервера для нової збірки.
2. Зміст файлу PDB
Офіційно розпочинаючи контент PDB, PDB не є публічно доступним форматом файлу, але Microsoft надає API для отримання даних з PDB.
Рідний PDB C++ містить таку інформацію:
* публічні, приватні та статичні функціональні адреси;
* Назва та адреса глобальної змінної;
* Імена параметрів і локальних змінних і зсув на стеку;
* визначення типів класу, структури та даних;
* Дані про пропуск вказівника кадру для проходження нативного стеку на x86;
* Ім'я та кількість рядків у файлі вихідного коду;
PDB .NET містить лише 2 частини інформації:
* Ім'я файлу вихідного коду та кількість рядків;
* та назву локальної змінної;
* Всі інші дані вже включені у . Метадані NET;
|
Опубліковано 03.08.2017 14:13:01
|
|
|
|
