Zwolnij generowanie plików .pdb, dlaczego?

Dlaczego program Visual Studio 2005 generuje .pdbpliki podczas kompilacji w wersji? Nie będę debugować wersji wydania, więc dlaczego są one generowane?

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:

1. 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.

2. 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.

3. 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.}

PDB można wygenerować zarówno dla, Releasejak i dla Debug. Ustawiono na (w VS2010, ale w VS2005 musi być podobny):

Projekt → Właściwości → Kompilacja → Zaawansowane → Informacje debugowania

Po prostu zmień na None.

Bez plików .pdb przejście przez kod produkcyjny jest praktycznie niemożliwe; musisz polegać na innych narzędziach, które mogą być kosztowne i czasochłonne. Rozumiem, że możesz na przykład użyć śledzenia lub windbg, ale tak naprawdę zależy to od tego, co chcesz osiągnąć. W niektórych scenariuszach chcesz po prostu przejść przez zdalny kod (bez błędów i wyjątków), używając danych produkcyjnych do obserwowania określonego zachowania, i tu właśnie przydają się pliki .pdb. Bez nich uruchomienie debugera dla tego kodu jest niemożliwe.

Dlaczego masz pewność, że nie będziesz debugować kompilacji wersji? Czasami (mam nadzieję, że rzadko, ale zdarza się) możesz otrzymać raport o usterce od klienta, który z jakiegoś powodu nie jest powtarzalny w wersji debugowania (różne czasy, małe inne zachowanie lub cokolwiek innego). Jeśli problem wydaje się powtarzalny w kompilacji wydania, z przyjemnością otrzymasz pasujący plik pdb.

Możesz także użyć zrzutów awaryjnych do debugowania oprogramowania. Klient wysyła go do Ciebie, a następnie możesz go użyć do zidentyfikowania dokładnej wersji Twojego źródła - a Visual Studio pobierze nawet odpowiedni zestaw symboli debugowania (i źródła, jeśli jesteś poprawnie skonfigurowany) za pomocą zrzutu awaryjnego. Zobacz dokumentację Microsoft dotyczącą sklepów z symbolami .

Plik .PDB to krótka nazwa „Baza danych programu”. Zawiera informacje o punkcie debugowania debugera i używanych zasobach lub odwołanie. Jest generowany, gdy budujemy jako tryb debugowania. Pozwala aplikacji na debugowanie w czasie wykonywania.

Rozmiar to wzrost pliku .PDB w trybie debugowania. Jest używany podczas testowania naszej aplikacji.

Dobry artykuł z pliku pdb.

http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P

W rozwiązaniu obejmującym wiele projektów zwykle chcesz mieć jedną konfigurację, która nie generuje żadnych plików PDB ani XML. Zamiast zmieniać Debug Infowłaściwość każdego projektu na none, pomyślałem, że bardziej celowe byłoby dodanie zdarzenia po kompilacji, które działa tylko w określonej konfiguracji.

Niestety, Visual Studio nie pozwala na określenie różnych zdarzeń po kompilacji dla różnych konfiguracji. Zdecydowałem się to zrobić ręcznie, edytując csprojplik projektu startowego i dodając następujące (zamiast jakiegokolwiek istniejącego PostBuildEventznacznika):

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

Niestety spowoduje to, że pole tekstowe zdarzenia po kompilacji będzie puste, a umieszczenie w nim wszystkiego może mieć nieprzewidywalne wyniki.

Symbole debugowania ( .pdb) i dokument XML ( .xml) stanowią duży procent całkowitego rozmiaru i nie powinny być częścią zwykłego pakietu wdrożeniowego. Ale powinien być możliwy dostęp do nich w razie potrzeby.

Jedno z możliwych podejść: pod koniec procesu kompilacji TFS przenieś je do osobnego artefaktu.

W rzeczywistości bez plików PDB i posiadanych przez nich informacji symbolicznych niemożliwe byłoby utworzenie udanego raportu o awarii (pliki zrzutu pamięci), a Microsoft nie miałby pełnego obrazu, który spowodował problem.

Tak więc posiadanie PDB poprawia raportowanie awarii.