2012-06-15 12 views
6

Jakiś czas temu przeczytałem artykuł o CLR, gdzie autor pokazał, że jeśli projekt jest kompilowany w trybie DEBUG, zanim każdy operator otrzyma polecenie NOP, co pozwoli na debugowanie kodu. Niemniej jednak, dzisiaj odkryłem, że możemy również debugować w trybie zwolnienia również ... Proszę, pomóżcie zrozumieć różnicę.Debugowanie w .NET w trybie Release

+1

Jak? Naprawdę nie wiem jak można debugować w trybie Release – crassr3cords

+0

Napotkałem, że nie mogę przejść do innych asseblies podczas debugowania w trybie zwolnienia –

Odpowiedz

1

Możesz debugować w trybie Release w pewnym zakresie. Debugowanie i wydawanie to po prostu konfiguracje kompilacji (z których można utworzyć wiele), rzeczywistą różnicą jest to, że konfiguracja debugowania nie optymalizuje wygenerowanego kodu binarnego (zoptymalizowany kod komplikuje debugowanie). Generuje także dodatkowe dane debugowania, których nie ma.

+0

Więc Mówisz, że Konfiguracja debugowania komplikuje debugowanie? –

+0

Nie, przepraszam, powiedziałem, że optymalizacja kodu komplikuje debugowanie. Przeredaguję to, aby nie było to mylące. – erodewald

5

debugowanie kodu NET, dzięki czemu można zwiększyć za pomocą kodu źródłowego, gdy jest on wykonywany zwykle wymaga trzech rzeczy:

  • Symbole (powiązany plików .pdb), które powstawały wraz z montażem. dll lub exe
  • Źródło (powiązane .cs, .vb itp pliki)
  • wykonujący kod maszyna musi być unoptimized

Symbole są kontrolowane przez flagę /debug:{full | pdbonly}. Jeśli podasz /debug:full (nawet w kompilacji wydania, przy wyłączonych optymalizacjach kompilatora) możesz dołączyć do już działającego procesu i przejść przez kod. Jeśli masz /debug:pdbonly, musisz użyć debuggera, aby uruchomić program (i nie możesz wyświetlać symboli podczas dołączania do już działającego procesu).

Optymalizacja jest kontrolowana przez opcję granularly /debug kompilatora, ale może być dodatkowo kontrolowane przez /optimize-.

2

Kompilacja w trybie zwolnienia optymalizuje wynikowy plik binarny, co utrudnia (ale nie uniemożliwia) debuggerowi określenie, który kod binarny pochodzi z linii linii kodu źródłowego.

Tryb debugowania ma na celu ułatwienie debuggera "podążania wzdłuż", dzięki czemu oddziela on wiersze kodu od NOP i nie optymalizuje wynikowego pliku binarnego.

+0

Mam na myśli, że to dziwne, że tak duża kontrola nad tymi procesami. Ponieważ dzisiaj zobaczyłem, że mój kolega bezproblemowo debugował kod w trybie Release i kiedy go o to zapytałem, nie wiedział. –

+0

Bez symboli debugowania (plik .pdb) debugger nie będzie wiedział, jaki był oryginalny kod źródłowy, ale nadal będzie mógł przejść przez kod binarny. AFAIK, debugger może dołączyć do dowolnego procesu, który chce i przejść przez niego. System operacyjny daje wiele uprawnień do debuggerów. –

+0

Hm, więc będzie trudniej debuggera, ale nadal możliwe? (Mam na myśli, bez pliku pdb)? –

Powiązane problemy