Co to jest debugattach.aspx i dlaczego serwer nie może go znaleźć?

Question

Pracuję na maszynie XP (SP3) z VS 2010 i IIS 5.

Mam dwie wersje tej samej witryny. Opublikowaliśmy naszą pierwszą wersję produkcyjną, więc rozwinąłem kod do nowego drzewa katalogów i skonfigurowałem nowe katalogi wirtualne w IIS, aby wskazywały nowe drzewa. Projekty są skonfigurowane do działania w IIS, a nie w serwerze VS. Strona główna to projekt oparty na MVC 2.

Mój problem polega na tym, że po naciśnięciu klawisza F5 w programie Visual Studio 2010, aby rozpocząć debugowanie nowej wersji, pojawia się komunikat "Nie można rozpocząć debugowania na serwerze sieci Web. Serwer WWW nie może znaleźć żądanego zasobu". Spędziłem większą część wczoraj, próbując dowiedzieć się, jakiego zasobu szukał, czego nie mógł znaleźć. Dzieje się tak, zanim dojdzie do "rozpoczęcia aplikacji". W końcu pomyślałem o przejrzeniu logów sieciowych i stwierdziłem, że za każdym razem, gdy wciskam klawisz F5, dziennik internetowy pokazuje żądanie DEBUG dla/debugattach.aspx, z kodem powrotu 404 (nie znaleziono). Jeśli uruchomię tę samą sekwencję w starej wersji, pokazuje to samo, ale najpierw z kodem 401, a następnie żądanie powtórzone z kodem 200.

Moja pierwsza myśl była taka, że ​​VS musi wypisać plik "debugattach.aspx", a następnie wywołać go, a może nie ma prawa zapisu do katalogu, ale, o ile mogę to stwierdzić, robi.

Mam goedugled debugattach.aspx, a pierwsze kilka stron artykułów, które są zwracane, wydaje się odnosić do blokady i limitów czasu, głównie na IIS 7 i VS 2005. Nic, co wydaje się mieć zastosowanie do tej sytuacji.

Patrząc na to, co różni się od starej wersji, która działa, a do nowej wersji, która nie działa, jedyną rzeczą jest konfiguracja katalogów wirtualnych usług IIS i plik web.config na samym kodzie. Ale przeszedłem dwie strony obok siebie i nie mogę znaleźć żadnych różnic, które uwzględniałyby to zachowanie.

Czy ktoś ma wskazówkę, którą może mi udostępnić? Czy ktoś może wskazać mi jakąkolwiek dokumentację na temat tego, czym dokładnie debugattach.aspx jest/robi i co robi żądanie HTTP DEBUG i/lub jak VS je wykorzystuje?

Z góry dziękuję.

Answer 1

Dodaj <compilation debug="true"> do swojego pliku Web.config.

Answer 2

Ja też w to wpadłem. Wyłączyłem Zezwalaj na niepubliczne nazwy plików, podając ustawienie pod Żądaj filtrowania na moim lokalnym serwerze IIS (w celu dopasowania naszych ustawień zabezpieczeń hardened w innych środowiskach). Okazuje się, że .aspx był blokowany. Ponownie włączyłem ustawienie i mogłem dołączyć do debuggera. Więc wyłączyłem go i dodałem dodatek na poziomie witryny dla .aspx i mogę ponownie dołączyć do debuggera.

Jestem również ciekawy, dlaczego debugger szuka debugattach.aspx, i nie udało się z tym błędem. Zwłaszcza, że ​​moja aplikacja jest MVC i nie muszę obsługiwać .aspx.

Answer 3

Posiadałem mapę skryptów wieloznacznych dla wersji .net 4 pliku aspnet_isapi.dll, który powodował to. Udało mi się zmienić mapowanie skryptów, aby zignorować czasownik DEBUG (używając tylko czasowników potrzebnych do mojej aplikacji) i umożliwić automatyczne łączenie VS.

Powiedziawszy to, w końcu użyłem serwera WWW VS lub IIS Express, aby moja witryna działała na maszynie XP, ponieważ IIS 5.1 nie polubił kombinacji map skryptów wieloznacznych i routingu ASP.NET .

Answer 4

Na podstawie this old posting, DebugAttach.aspx jest zaimplementowany przez procedurę obsługi HTTP System.Web.HttpDebugHandler. W rzeczywistości nie widziałem tego programu obsługi w Nigdzie w IIS7 - możliwe, że ta implementacja została scalona z innym programem obsługi w dalszej części. Zdecydowanie jakiś przewodnik. Kiedy działa, w dziennikach pojawia się 200 (sukces) wiadomości.

Miałem ten sam problem na 2 różne sposoby, w których nie powiodło się debugowanie F5 w VS2010 z powodu problemów z obsługą debugera. Korzystając z dzienników śledzenia żądań usług IIS nie powiodło się, mogłem zobaczyć wystąpienia, w których interferują moduły IIS. W jednym przypadku UrlScan.dll blokował czasownik DEBUG. W innym, przekierowanie z HTTP do HTTPS spowodowało, że program do debugowania zwrócił kod 302. W obu przypadkach VS był podawany z podobnym dialogiem.

W każdym razie podstępem wydaje się być ustalenie, w jaki sposób można zablokować żądanie DEBUG do tego adresu URL.

Answer 5

Jeśli używasz VS2010 lub nowszego i masz zainstalowany .Net 4.x lub nowszy, spróbuj zmienić nazwę podkatalogu "v3.0" (np. "Zmień nazwę C: \ Windows \ Microsoft.Net \ Framework \ v3. 0 v3.0.ORIGINAL "), uruchom ponownie komputer i spróbuj ponownie debugować w Visual Studio.

To działa dla mnie jak cholerny urok, ale twój przebieg może się różnić, w zależności od tego, jaki rodzaj rozwoju robisz.

Używam Visual Studio 2012 przez dwa tygodnie w ten sposób, a ja naprawdę nie mogę uwierzyć, jak szybko rzeczy są (znowu!). Uruchomienie debuggera za pomocą F5 jest natychmiastowe, a zatrzymanie sesji debugowania jest natychmiastowe. Wszystkie rodzaje zachowań ryzykownych i opóźnionych ustały i jak dotąd nie widziałem pojedynczego efektu ubocznego.

Answer 6

Rozwiązaniem, które działa na mnie było ponowne uruchomienie VStudio w trybie Uruchom jako administrator.