Wiele osób z pewnością kojarzy pliki PDB, przynajmniej z nazwy. Myślę, jednak, że w praktyce mało kto zdaje sobie sprawę co one zawierają i kiedy mogą się przydać programiście. W poście zatem chciałbym przybliżyć praktyczne korzyści z używania Program Database Files.

Z pewnością PDB kojarzy się z debuggowaniem i niestety z czymś niepotrzebnym w środowisku produkcyjnym – co jak się okaże jest nieprawdą! Zacznijmy od wprowadzenia teoretycznego, PDB dla .NET  zawiera:

1. Nazwy plików z kodem źródłowym.
2. Nazwy lokalnych zmiennych.
3. Numery linii kodu.

Wszystkie inne dane  są zawarte już w plikach binarnych (DLL, EXE itp) i metadanych. W przypadku aplikacji CPP, PDB przechowują dużo więcej danych ale o C++ nie będę pisał tutaj.

Kiedy Windows ładuje bibliotekę do pamięci poszukuje również odpowiedniego pliku PDB. Na przykład, jeśli uruchamiamy HelloWorld.exe, Windows również będzie próbował znaleźć HelloWorld.pdb. Każda plik binarny oraz odpowiadający mu PDB posiadają wspólny unikalny ID (GUID). Podczas każdej kompilacji generowany jest nowy GUID. Jeśli PDB ma inny GUID niż biblioteka, niemożliwe będzie wykorzystanie ich podczas debuggowania (id muszą być jednakowe).

Myślę, że na początek tyle informacji wystarczy. Nie chce zanudzać więcej o rzeczach takich jak lokalizacje PDB czy DUMPBIN (narzędzie służące do odczytywania GUID). Sprawdźmy w praktyce, jak nam może pomóc PDB. Zmieńmy najpierw typ kompilacji na RELEASE i w jakieś metodzie umieśćmy następujący kod, wywołujący wyjątek (dzielenie przez zero):

try
{
 int localVar = 54;
 int val = 0;
 int result = localVar/val;
}
catch (Exception e)
{
 MessageBox.Show(e.ToString());
 throw;
}  

Po kompilacji zobaczymy, że plik PDB został wygenerowany:

Odpalmy aplikacje i zobaczmy jakie informacje dostaniemy po wyrzuceniu wyjątku:

Zgodnie z tym co zawiera PDB, dostaliśmy bardzo ważną wskazówkę: numer linii kodu oraz nazwę pliku źródłowego. Z pewnością za pomocą takiej informacji bardzo łatwo zlokalizować błąd. Usuńmy teraz plik pdb aby przekonać się, że faktycznie bez niego nie dostaniemy tej informacji:

Na maszynie developerskiej zawsze mamy pod ręką VS. Problemy zaczynają się na innych komputerach (środowisko produkcyjne, komputery testerów itp.). Sam wyjątek w pliku logów niewiele mówi programiście. Nazwa pliku i numer zawęża maksymalnie pole do poszukiwań. Dlatego warto pliki PDB deployować wraz z plikami binarnymi. Niektórzy programiści mogą być niechętni deployować PDB ze względów bezpieczeństwa . Jednak dla większości aplikacji nie ma to znaczenia – jeśli deployujemy pliki binarne to i za pomocą czystego Reflect’ora wiele informacji o strukturze aplikacji można uzyskać. Oczywiście PDB ułatwiają trochę zadanie potencjalnemu hackerowi ale jeśli istnieje jakaś luka w systemie wcześniej czy później zostanie ona wykorzystana. Każdy sam musi oszacować ryzyko ale szczególnie dla klientów korporacyjnych, myślę, że PDB dostarcza dużo więcej korzyści niż wad – w końcu w razie awarii możemy bardzo szybko zareagować