Wczoraj z rana odpaliłem swoje środowisko pracy, włączyłem debugowanie, zaznaczyłem breakpoint w akcji na zwrócenie widoku i wklepałem odpowiedni URL. Niby standard? Każdy z nas to robi ;) prędzej czy później.
Różnica między mną a wami jest taka, że mi aplikacja nie zatrzymała się na breakpoint. Myśle sobie, dziwne, ale ok, F5 w przeglądarce i breakpoint zadziałał jak trzeba. Posprawdzałem, pozmieniałem i odpalam ponownie aplikację.
Nim mi się cokolwiek pokazało, VS wychwycił mi mój breakpoint… zaraz ale przecież nie powinien, to jest inna akcja? Myślę sobie, że znów mam problem z VS który nie pamięta, że wyłączyłem breakpointy pomiędzy sesjami debugującymi (tak, zdarza mi się to). Jednak patrzę w kod i widzę, żę breakpoint który został wychwycony należy do akcji którą przed chwilą debugowałem.
Zdziwiony klikam continue i wchodzę na tą akcję… breakpoint nie jest wyłapany. Po odświeżeniu strony jest. Zaczynam się głowić co jest grane, ustawiam więc breakpoint na akcję, która jest ładowana podczas rozpoczynania debuggowania. I o to wynik:
Sprawdzam więc wszystkie informacje a temat requestu jakie mam w mojej akcji – null, zero, nil.
Wyłączam więc Glimpse – i dalej mam to samo. Odinstalowuje Glimpse – i dalej mam to samo.
Piszę testy by się upewnić, że nie ma kolizji routingu:
All wydaje się poprawne. Fiddler i IIS Express, logują jednak requesty do mojej testowanej akcji:
Robię restart VS, restart komputera i bez zmian.
Sprawdzam więc co się dzieje kiedy nie odpalam debuggera (CTRL+F5 w VS). Fiddler i IIS Express nie logują już requestów do mojej akcji którą chcę debuggować. Dziwne. Czyli problem leży gdzieś pomiędzy startem debuggowania i routingiem.
Robię prosty test, usuwam domyślny routing i pozostawiam tylko ten który jest określony:
Odpalam aplikację i all jest jak należy. Ok, czyli pewnie kłopot z routingiem, ale gdyby to był ten problem to by występował zawsze a nie tylko na początku. Ostatni test: przywrócenie domyślnego routingu, ale ustawienie specyficznego dla mojej akcji – jak wiemy, routing działa od specjalizacji do globalizacji. Czyli jeżeli to jest wina routingu, to jak przechodzimy po tablicy routowania, to moja testowana akcja powinna zawierać url przeze mnie ustawiony bo zostanie on wychwycony i zwrócony zanim dosięgniemy domyślnego routingu.
Jednak tak się nie dzieje. Wciąż request jest wykonywany do /adminuserslist/list
Zadałem więc pytanie jednemu z dev czy ma taki sam problem – odpisał, że nie ma (whaaat???). Jak się o tym dowiedziałem, to się naprawdę wkurzyłem :) znów u mnie na kompie nie działa :)
I na tym, po 6h analizowania i debuggowania skończyłem. Szczerze nie wiem czemu się tak dzieje. Dalej tak mam, restarty, czyszczenie ceche itp. itd. nie pomagają. Próba debugowania z symbolami MSowymi kończy się na tym, że po X minutach ładowania symboli mam dość i ubijam proces.
Bardzo chciałbym się dowiedzieć dlaczego się tak dzieje, ale też nie mam pomysłów co mogę i jak mogę dalej to testować. Także, problem występuje tylko i wyłącznie na mojej maszynie (z tego co się pytałem) i jest on stricte związany z odpalaniem aplikacji w debug mode :(
Może wy drodzy czytelnicy będziecie wiedzieć, co mogę jeszcze sprawdzić? A może ktoś z was natrafił na taki problem? Jeżeli tak, to jak go rozwiązaliście? Jakakolwiek pomoc będzie bardzo mile widziana.
Hej, może masz jakiś if #DEBUG w kodzie? :)
No i pytanie czy może to być wina aktualizacji do VS2013.1…
Przekopiuj apke na inne miejsce na dysku i sprawdz z nowej lokalizacjji czy nadal masz problem.
**@krajew4**
`if #DEBUG` nie ma nigdzie :)
co do VS2013.1 – conajwyzej moze to byc spowodowane odinstalowaniem VS2013.2 o czym wspominalem [ostatnio](http://blog.gutek.pl/2014/05/13/vs2013-2-i-visual-studio-2013-color-theme-editor).
**@zchpit**
nadal, nowa lokalizacja, ten sam problem. jestem pewny ze to jest cos nie tak z moim kompem bo nie wierze ze to wina .NET framework, inaczej dalej by tak dzialalo wszedzie.
Moze informacja ze od czasu do czasu dostaje blue screens z niewiadomego powodu cos powie. w logach nie mam informacji o tym, ale to albo `DPC_WATCHDOG_VIOLATION` (rzadko, i nie wiem dlaczego, mam wszystkie drivers najnowsze) albo `CRITICAL` cos tam (nie pamietam :/)
Proponuję przed poszukiwaniem błędów w VS zmienić przeglądarkę na inną. Sprawdź także czy masz wszystkie łatki z IIS związane. Kiedyś muałem problem, że IIS źle rozpoznawał przeglądarkę i wysyłał do niej głupoty. Może tutaj masz podobnie?
**@Grzegorz W**
na IIS nie stawialem, na IIS Express all dziala – czyscilem cache (usuwalem tez apke z IIS Express) i tez sprawdzalem na prawie wszystkich przegladarkach (jedynie na IE nie). Problem dalej istnieje i tylko przy startupie :/
A nie masz ustawionych jakiś rewrite’ów na IIS??
*Jakichś
**@czaja**
nie, to jest IIS Express, domyslny web config itp. Do tego co warto tutaj zwrocic uwage ze jak odpalam bez debuggowania, to ta akcja nie jest wywolywana. jedynie jest kiedy robie F5 i podlaczam debugger i tylko za pierwszym razem.
Gdyby byl IIS Rewrite to by to sie dzialo za kazdym razem nie zaleznie od tego czy debugger jest zalaczony czy tez nie – przynajmniej tak mi sie zdaje :)
Może akcja w stylu: “Zrzuta na maszynę dla gutka”? tylko najlepiej używana przez kogoś, komu te wszystkie kody działają :-)
Comments are closed.