Wyłączenie z debugowania w VS kawałka kodu.

Mam problem. Ogromna aplikacja i chciałbym zacząć debugować kod po wciśnięciu jakiegoś przycisku, bez wcześniejszego znalezienia tego kawałka kodu i wstawiania tam breakpointa.

Przy debugowaniu służy do tego przycisk pauzy. Jak go naciśniemy debugowanie zaczyna się w kodzie, który akurat się wykonuje lub zacznie wykonywać po wystąpieniu jakiegoś eventu. Problem w tym, że pewna ważna pętla aplikacyjna chodzi w kółko kilkanaście razy na sekundę. Jak nacisnę tą pauzę to zawsze mi wskakuje debugger od razu do tej pętli, a chciałbym by ją całkowicie ignorował a złapał mi event z wciśnięcia przycisku.

kod po wciśnięciu jakiegoś przycisku

no to skoro masz ten przycisk to zobacz pod co jest podpiety (pod jaka funkcje) i wstaw tam breakpoint

Znalezienie tego przycisku jest zbyt czasochłonne za każdym razem. Aplikacja jest tak wielka, że nawet po nazwie nie mogę się domyślić, w którym projekcie siedzi ta formatka.

przeciez go naciskasz. Skoro wiesz gdzie go znalezc w aplikacji zbudowanej to ja nie widze zadnego problemu w znalezieniu go w kodzie.

Nastepnym razem zostaw sobie tam breakpoint, a jak skonczysz z debugowaniem to go wylacz (disable) ale nie usuwaj. Dzieki temu bedziesz miec na liscie breakpointow

Jest taki atrybut. Możesz go zdefiniować nad np. metodą
https://msdn.microsoft.com/en-gb/library/system.diagnostics.debuggerstepthroughattribute.aspx

fasadin napisał(a):

przeciez go naciskasz. Skoro wiesz gdzie go znalezc w aplikacji zbudowanej to ja nie widze zadnego problemu w znalezieniu go w kodzie.

Wierz mi, że jest to pracochłonny proces. Tym bardziej, że aplikacja się składa z 4 solucji i zaciąga nugetem zbudowane paczki z innych solucji. I nawet nie wiesz czy dany przycisk nie jest w formatce z innej solucji.

fasadin napisał(a):

Nastepnym razem zostaw sobie tam breakpoint, a jak skonczysz z debugowaniem to go wylacz (disable) ale nie usuwaj. Dzieki temu bedziesz miec na liscie breakpointow

Zakładki też fajne narzędzie ;D

No dobra, domyślam się, że ta pętla idzie w innym wątku. Ale przecież masz odpowiednie do tego narzędzia. Masz call stacka i listę wątków. Jak sobie przełączysz wątek w tym okienku, to zobaczysz call stacka właśnie dla niego. Więc może w ten sposób dojdziesz do tego przycisku.

Juhas napisał(a):

No dobra, domyślam się, że ta pętla idzie w innym wątku. Ale przecież masz odpowiednie do tego narzędzia. Masz call stacka i listę wątków. Jak sobie przełączysz wątek w tym okienku, to zobaczysz call stacka właśnie dla niego. Więc może w ten sposób dojdziesz do tego przycisku.

Dobrze się domyślasz ;)
Niestety jak nacisnę pauzę ("Break All") freezuje mi przecież GUI, w którym nic nie kliknę, więc nie pójdzie to zdarzenie do innego wątku. Break All łapie zdarzenia ze wszystkich wątków, a nie tylko wybranego albo z pominięciem niektórych wątków. :( Wątek można wybrać dopiero jak dojdzie do break i debugowania w kodzie, nie wcześniej.

1. Włączasz aplikację z debugerem,
2. Pauzujesz aplikacje (Break All) a następnie Step Out (F11)
3. Odpalasz buttona - debugger wskakuje w delegatę

Wierz mi, że jest to pracochłonny proces. Tym bardziej, że aplikacja się składa z 4 solucji i zaciąga nugetem zbudowane paczki z innych solucji.

ja pracuje gdzie jedna solucja ma 138 projektow. Takich solucji mamy pare a mniejszych solucji mamy 25. Jakos znalezc mi cos w aplikacji nie jest trudno

Tak paczki tez sa budowane z nugetem. Takze wybacz, ale nie moge Ci uwierzyc, ze jest to az tak trudne.

śmieszek napisał(a):

1. Włączasz aplikację z debugerem,
2. Pauzujesz aplikacje (Break All) a następnie Step Out (F11)
3. Odpalasz buttona - debugger wskakuje w delegatę

Po naciśnięciu Step Out (F11) program wychodzi ze stanu Break All od razu.

fasadin napisał(a):

Wierz mi, że jest to pracochłonny proces. Tym bardziej, że aplikacja się składa z 4 solucji i zaciąga nugetem zbudowane paczki z innych solucji.

ja pracuje gdzie jedna solucja ma 138 projektow. Takich solucji mamy pare a mniejszych solucji mamy 25. Jakos znalezc mi cos w aplikacji nie jest trudno

Tak paczki tez sa budowane z nugetem. Takze wybacz, ale nie moge Ci uwierzyc, ze jest to az tak trudne.

Jeśli brałeś udział w sporej części tworzenia oprogramowania to wiesz co gdzie jest. Ja mam taką solucję ma prawie 100 projektów (i tak mało bo korzysta z dziesiątek serwisów, do których na szczęście nie muszę zaglądać za często), o aplikacji wiem bardzo mało, nawet gubię się interfejsie użytkownika. Skąd mam wiedzieć, w którym projekcie zakopana jest formatka? Pozostaje zgadywanie nazwy class przy wsparciu resharpera i grepowanie solucji po stringach z UI, które i tak są zaciągane w dużej mierze z trzech serwisów.

Serio jakbym cię posadził przed dużą solucją, którą pierwszy raz widzisz na oczy potrafiłbyś od razu wskazać w kodzie tu jest formatka, którą widzę teraz w aplikacji?

@zimny Szczur, rozwiązanie podane przez @error91 nie działa?