No właśnie... moje pytanie jest takie, czy debugując kod używając (f11 - step into) widzimy cały wykonywany kod? Bo czasem wydaje mi się, że poza tym co widać wykonują się jeszcze jakieś operacje. Tak więc czy istnieje jeszcze dokładniejszy sposób śledzenia kodu?
0
0
Jeżeli masz aplikację wielowatkową to może to tak wyglądać. Czasem też zdarzało mi się że komplacja przechodziła ale kod był wykonywany przed zmianami wtedy też wypisywał głupoty, od 2010 nie obserwuję takiego zachowania w Visual Studio.
Jeżeli obserwujesz kod i widzisz dzine rzeczy to monitoruj System.Threading.Thread.Current w oknie Watch zobaczysz czy to ten sam wątek.
Jakbyś chiał jakieś konkretniejsze wyjasnienie to opisz dokładniej jakie obserwujesz zachowanie, na jakim kodzie i czego sie spodziewasz.
0
Dobre masz wrażenie. Możesz debugować tak głęboko jak głęboko posiadasz pliki .pdb dla danej biblioteki. Używanie "watcha" też może czasami zaburzyć cały proces debugowania. Podglądając w "watchu" jakieś property najzwyczajniej w świecie wykonujesz tan kod, a gdy ktoś na get wykonuje jakieś akcje to one też się wykonają mimo, że breakpointem stoisz zupełnie gdzie indziej.
0
Jeśli masz włączone optymalizacje to też mozesz przeskakiwać nad kodem, który został zoptymalizowany (zmienił się w stosunku do tego co sam napisałeś).
debugger może też pomijać funkcje zadeklarowane w biblioteczkach jako kod asm. W przypadku wyższych wersji (bodajże proffessionall) może zapytać, czy pokazać kod assemblera ;)