Ponieważ bez plików PDB niemożliwe byłoby debugowanie kompilacji „Release” za pomocą czegoś innego niż debugowanie na poziomie adresu.Optymalizacje naprawdę mają wpływ na Twój kod, przez co bardzo trudno jest znaleźć winowajcę, jeśli coś pójdzie nie tak (powiedzmy, zgłoszono wyjątek). Nawet ustawienie punktów przerwania jest niezwykle trudne, ponieważ wierszy kodu źródłowego nie można dopasować jeden do jednego z (lub nawet w takiej samej kolejności jak) wygenerowanym kodem asemblera. Pliki PDB pomagają tobie i debuggerowi znacznie ułatwić debugowanie pośmiertne.
Chodzi o to, że jeśli oprogramowanie jest gotowe do wydania, do tego czasu należy wykonać wszystkie debugowanie. Chociaż jest to z pewnością prawda, należy pamiętać o kilku ważnych kwestiach:
Powinieneś także przetestować i debugować swoją aplikację (przed jej wydaniem) za pomocą kompilacji „Release”. Wynika to z faktu, że włączenie optymalizacji (domyślnie są wyłączone w konfiguracji „Debugowanie”) może czasami powodować pojawienie się subtelnych błędów, których w innym przypadku nie złapałbyś. Podczas debugowania potrzebne będą symbole PDB.
Klienci często zgłaszają przypadki i błędy, które pojawiają się tylko w „idealnych” warunkach. Są to rzeczy, które są prawie niemożliwe do odtworzenia w laboratorium, ponieważ opierają się na jakiejś dziwnej konfiguracji maszyny tego użytkownika. Jeśli są szczególnie pomocnymi klientami, zgłoszą zgłoszony wyjątek i podadzą ślad stosu. Albo nawet pozwolą ci pożyczyć ich maszynę do zdalnego debugowania oprogramowania. W obu przypadkach potrzebne będą pliki PDB.
Profilowanie należy zawsze wykonywać w kompilacjach „Release” z włączonymi optymalizacjami. I znowu, pliki PDB są przydatne, ponieważ pozwalają na odwzorowanie instrukcji asemblowania z powrotem na kod źródłowy, który napisałeś.
Nie można wrócić i wygenerować plików PDB po kompilacji. * Jeśli nie stworzysz ich podczas kompilacji, stracisz swoją szansę. Ich tworzenie nie zaszkodzi. Jeśli nie chcesz ich rozpowszechniać, możesz po prostu pominąć je w plikach binarnych. Ale jeśli później zdecydujesz, że ich chcesz, nie masz szczęścia. Lepiej zawsze je generuj i archiwizuj kopię, na wypadek, gdybyś ich kiedykolwiek potrzebował.
Jeśli naprawdę chcesz je wyłączyć, zawsze jest to opcja. W oknie Właściwości projektu ustaw opcję „Informacje debugowania” na „brak” dla dowolnej konfiguracji, którą chcesz zmienić.
Należy pamiętać jednak, że „Debug” i „uwolnienie” konfiguracje zrobić domyślnie użyć innych ustawień dla emitujących informacje debugowania. Będziesz chciał zachować to ustawienie. Opcja „Informacje debugowania” jest ustawiona na „pełna” dla kompilacji debugowania, co oznacza, że oprócz pliku PDB informacje o symbolach debugowania są osadzone w zestawie. Otrzymasz także symbole obsługujące ciekawe funkcje, takie jak edycja i kontynuacja. W trybie Release wybrana jest opcja „tylko pdb”, która, jak się wydaje, zawiera tylko plik PDB, bez wpływu na zawartość zestawu. Nie jest to tak proste, jak sama obecność lub brak plików PDB w /binkatalogu. Ale zakładając, że użyjesz opcji „tylko pdb”, plik PDB ”
* Jak zauważył Marc Sherman w komentarzu , dopóki twój kod źródłowy nie zmienił się (lub możesz pobrać oryginalny kod z systemu kontroli wersji), możesz go odbudować i wygenerować pasujący plik PDB. Przynajmniej zwykle. Działa to dobrze przez większość czasu, ale nie gwarantuje się , że kompilator generuje identyczne pliki binarne za każdym razem, gdy kompilujesz ten sam kod , więc mogą występować subtelne różnice. Co gorsza, jeśli w międzyczasie dokonałeś jakichkolwiek aktualizacji swojego zestawu narzędzi (takich jak zastosowanie dodatku Service Pack dla programu Visual Studio), PDB są jeszcze mniej prawdopodobne. Aby zagwarantować niezawodną generację ex postfactoPliki PDB, musisz zarchiwizować nie tylko kod źródłowy w systemie kontroli wersji, ale także pliki binarne dla całego łańcucha narzędzi kompilacji, aby zapewnić dokładne odtworzenie konfiguracji środowiska kompilacji. Oczywiste jest, że o wiele łatwiej jest po prostu tworzyć i archiwizować pliki PDB.