Nie można rozpocząć debugowania na serwerze internetowym. Nie można uruchomić debugowania ASP.NET VS 2010, II7, Win 7 x64

Używam programu Visual Studio 2010 (jako administrator), IIS 7 w systemie Windows 7 x64. Mogę uruchomić witrynę sieci Web ASP.NET w usługach IIS 7 bez debugowania, ale kiedy naciskam klawisz F5, aby ją debugować, otrzymuję:

Nie można rozpocząć debugowania na serwerze internetowym. Nie można rozpocząć debugowania ASP.NET. Więcej informacji można uzyskać, uruchamiając projekt bez debugowania.

Niestety łącze pomocy nie pomaga mi zbytnio i prowadzi do ogromnego drzewa rzeczy.

Sprawdziłem co następuje:

• Wymagania bezpieczeństwa - nie przypominam sobie, żebym wcześniej robił coś specjalnego. Proces roboczy w usługach IIS7 to w3wp.exe. Mówi, że jeśli działa jako ASPNET lub USŁUGA SIECIOWA, muszę mieć uprawnienia administratora, aby go debugować. Jak mogę się dowiedzieć, czy muszę tutaj coś zmienić?

• Strony właściwości witryny sieci Web> Opcje uruchamiania> Debugery> ASP.NET jest zaznaczona. Użyj serwera niestandardowego jest ustawiony na adres URL witryny (co działa bez debugowania).

• Debugowanie jest włączone w web.config.

• Aplikacja korzysta z ASP.NET 3.5 (ostatecznie chcę przejść na 4.0, ale muszę się zająć migracją).

• Pula aplikacji: Klasyfikacja .NET AppPool (wypróbowano również DefaultAppPool).

Jakieś pomysły, w których mogę sprawdzić dalej?

Z pewnością nie powinno być tak trudno zainstalować IIS, VS, utworzyć witrynę internetową i rozpocząć testowanie?

Z góry dziękuję.

Spróbuj przejść do usług IIS i sprawdź, czy jest uruchomiona pula aplikacji, której używasz. Wiele razy wystąpi błąd, który zamyka pulę aplikacji. Wystarczy kliknąć prawym przyciskiem myszy i rozpocząć, a wszystko powinno być gotowe.

Okazuje się, że winowajcą był moduł IIS Url Rewrite . Zdefiniowałem regułę, która przekierowuje wywołania do Default.aspx (która była ustawiona jako strona początkowa witryny ) do katalogu głównego witryny, tak żebym mógł mieć kanoniczny adres URL strony głównej. Jednak najwyraźniej VS miał z tym problem i pomylił się. Ten problem nie wystąpił, gdy używałem Helicon ISAPI_Rewrite, więc nawet nie przyszło mi do głowy, aby to sprawdzić.

Skończyło się na stworzeniu zupełnie nowej strony internetowej od podstaw i stopniowym przenoszeniu projektów / plików do mojego rozwiązania i przebudowie mojego web.config, aż się tego dowiedziałem! Cóż, przynajmniej teraz mam nieco czystszą stronę korzystającą z .NET 4.0 (na razie mam nadzieję, że nie napotkam żadnych ścian) - ale co za ból!

Program Visual Studio podczas uruchamiania spróbuje (z jakiegoś powodu) uzyskać dostęp do adresu URL:

/debugattach.aspx

Jeśli masz regułę przepisywania, która przekierowuje (lub w inny sposób przechwytuje), powiedzmy, .aspxpliki, gdzie indziej, otrzymasz ten błąd. Rozwiązaniem jest dodanie tej sekcji na początku swojej web.config„s <system.webServer>/<rewrite>/<rules>sekcji:

<rule name="Ignore Default.aspx" enabled="true" stopProcessing="true">
    <match url="^debugattach\.aspx" />
    <conditions logicalGrouping="MatchAll" trackAllCaptures="false" />
    <action type="None" />
</rule>

Zapewni to złapanie tego konkretnego żądania, nic nie zrobisz i, co najważniejsze, zatrzyma wykonywanie, aby żadne inne reguły nie zostały uruchomione. Jest to solidne rozwiązanie, więc nie krępuj się zachować go w pliku konfiguracyjnym do produkcji.

Z korzyścią dla innych w moim przypadku skonfigurowałem pulę aplikacji tak, aby korzystała z moich poświadczeń systemu Windows w celu uzyskania dostępu do udziału zasobów sieciowych. Od czasu ostatniego debugowania rozwiązania zresetowałem hasło systemu Windows. Zmienione hasło przechowywane w puli aplikacji i bada bing.

Jeśli ApplicationPool Identity jest ustawione konto niestandardowe, a hasło komputera zostanie zmienione, musisz zaktualizować swoje hasło

W moim scenariuszu były to zmiany w sekcji httpErrors w web.config, ustawiając ją w następujący sposób:

<httpErrors mode="Custom"> 

spowodował błąd „Nie można rozpocząć debugowania na serwerze internetowym”. Przywrócenie poprzedniej wartości „DetailedLocalOnly” rozwiązało problem. Zagłębiając się nieco głębiej, odkryłem, że przyczyną tego było tylko ustawienie błędu 401:

<httpErrors mode="Custom"> 
    <error statusCode="401" prefixLanguageFilePath="" path="/masterpages/500.html" responseMode="ExecuteURL" />
<httpErrors mode="Custom"> 

Skomentowanie linii błędu 401 również rozwiązało problem, poszedłem z tym, ponieważ mogę wtedy zachować niestandardową obsługę błędów i rozpocząć debugowanie.

Nadal nie mam pojęcia, dlaczego tak się dzieje.

Sprawdź pulę aplikacji. jeśli zostanie zatrzymany. uruchom go ponownie.

Miałem ten sam problem podczas próby debugowania modułu DNN (Dot Net Nuke). Okazało się, że musisz mieć debugowanie kompilacji = "true":

<compilation debug="true" strict="false" targetFramework="4.0"> 

w pliku web.config. Domyślnie w DNN jest fałsz. Oryginalne źródło tutaj: http://www.dnnsoftware.com/forums/forumid/111/postid/189880/scope/posts

Mam dokładnie ten sam problem po wdrożeniu modułu przepisywania.

Jeśli usunę wpisy przepisywania z mojego pliku web.config, debugowanie działa idealnie.

Aby to obejść, po prostu skomentowałem przepisywanie znaczników podczas debugowania, na przykład ...

<rewrite>
    <rules>
        <rule name="LowerCaseRule_1" stopProcessing="true">
            <match url="[A-Z]" ignoreCase="false" />
            <action type="Redirect" url="{ToLower:{URL}}" />
        </rule>
        <rule name="RedirectDefault.aspx_1" stopProcessing="true">
            <match url="(.*)default.aspx" />
            <action type="Redirect" url="{R:1}" redirectType="Permanent" />
        </rule>
    </rules>
</rewrite>

Następnie usuwam komentarze po debugowaniu.

To musi być błąd w programie Visual Studio 2010.

Wystąpił ten sam błąd, ponieważ pula aplikacji została zatrzymana w usługach IIS. Po uruchomieniu puli aplikacji problem został rozwiązany.

Oto, co zrobiłem, aby usunąć zanotowany błąd. Zlokalizuj folder sieciowy aplikacji w systemie plików, przejdź do Właściwości => Zabezpieczenia kliknij przycisk Zaawansowane , a następnie kliknij kartę Właściciel , kliknij przycisk Edytuj i zmień właściciela (z odpowiednimi uprawnieniami) folderu i zaznacz opcję „ Odnów właściciel na podkontenerach i obiektach ”. Kliknij „ Zastosuj ” ”, a następnie byłem w biznesie (mogłem debugować).

Mam nadzieję, że to zadziała dla kogoś innego.

W końcu naprawiłem to dla mojego pojedynczego rozwiązania, które to miało. Dwa projekty w rozwiązaniu zostały ustawione jako witryny w usługach IIS. Wszedłem i włączyłem personifikację ASP.Net w ramach uwierzytelniania dla obu projektów ... i VIOLA! WRESZCIE, koniec z tym irytującym błędem!

Otrzymałem ten sam komunikat o błędzie w programie VS 2012, ale nie działałem jako administrator. Kiedy uruchomiłem aplikację jako administrator, otrzymałem inną i nieco bardziej pomocną wiadomość (którą udało mi się zrozumieć). HTH

Jeśli pula aplikacji ma problemy z ponownym uruchomieniem lub po prostu nie chce, aby ponownie uruchomić, sprawdź, czy system Windows wykonał ostatnią aktualizację w programie ASP.NET w wersji 4.0 lub innej puli aplikacji. Tak właśnie się stało w moim przypadku. Po prostu ponownie uruchomiłem komputer, a następnie ponownie uruchomiłem pulę aplikacji ASP.NET v4.0 i wszystko znów działało!

Dan,

Oprócz sugestii Aarona wypróbuj poniższe

• Sprawdź, czy w witrynie internetowej usług IIS jest zaznaczone zintegrowane uwierzytelnianie systemu Windows
• Czy możesz debugować za pomocą Cassini zamiast IIS?

Wystąpił ten sam problem z systemem Windows 10 po włączeniu wszystkich funkcji okien usług IIS. Przełączono na system Windows 8.1 i ponownie wystąpił problem. Katalog główny znajdował się w witrynie internetowej o nazwie „ http: //MySite.local ” (nie dotyczy wersji systemu operacyjnego).

A rozwiązanie jest proste

• Edytuj plik hosts w %SystemRoot%\System32\drivers\etc\

• Dodaj linię z powiązaniem IP: 127.0.0.1 MySite.local

Ten błąd wystąpił dzisiaj z powodu defektu w kodzie, który ogromnie wiele razy powodował zalewanie usług IIS żądaniami. To zasadniczo zablokowało IIS, więc kiedy próbowałem debugować, upłynął limit czasu podczas próby uruchomienia debugera. Po prostu ponownie uruchomiłem IIS, co zajęło kilka minut i rozwiązało problem.

Z pewnością chciałbym, żeby ten błąd był mniej ogólny, wydaje się, że istnieje kilka różnych sposobów jego utworzenia.

Miałem ten sam problem w Visual Studio 2012 i 2013 na Windows 8.1. Dla mnie rozwiązaniem było dodanie uwierzytelniania systemu Windows do usług IIS za pomocą opcji „Włącz lub wyłącz funkcje systemu Windows”

Upewnij się, że pula aplikacji Twojej witryny używa poprawnej wersji struktury . Otrzymałem błąd „Nie można rozpocząć debugowania” w witrynie ASP.Net 2005. Błędnie korzystał z DefaultAppPool w systemie Windows 7 (który, jak sądzę, korzystał z .Net Framework 4). Utworzyłem nową pulę aplikacji w oparciu o .Net Framework 2 i przypisałem ją do witryny, w której występuje problem. Po tym debugowaniu działało dobrze.

Sprawdź, czy Twoja witryna internetowa w usługach IIS się nie kończy.

Naprawiłem to i uruchomiłem moją witrynę internetową. :RE

Miałem ten problem i ostatecznie zdałem sobie sprawę, że I ASP.net nie jest poprawnie zarejestrowany w IIS. Może się to zdarzyć, gdy serwer IIS jest zainstalowany przed programem Visual Studio. Aby rozwiązać ten problem, użyj polecenia aspnet_regiis -i Więcej informacji można znaleźć w odsyłaczu

miał ten sam problem. Jeśli masz zainstalowany certyfikat SSL w usługach IIS i próbujesz go debugować w programie Visual Studio, musisz ustawić aplikację w usługach IIS, aby ignorowała certyfikat.

Miałem ten sam problem i stwierdziłem, że jest on spowodowany błędnym wpisaniem znaku Web.configpo tagu końcowym. My Web.configwyglądało to na samym końcu: </section>h. „H” był dodatkowym znakiem po zamykającym tagu.

usuń żądło w ten sposób: targetFramework = "4.0" w web.config lub zmień AppPool na odpowiednią wersję frameworka.

Odinstalowanie rozszerzenia IIS UrlScan rozwiązało problem za mnie.

Miałem ten sam problem, ale był to na własnym serwerze programistycznym Visual studios zamiast na IIS. Obejście polega na usunięciu zaznaczenia opcji na karcie Sieć we właściwościach projektu, Zastosuj ustawienia serwera do wszystkich użytkowników (zapisz w pliku projektu). Zaoszczędzi to komuś cenny czas.

Miałem ten sam problem. Wszystkie powyższe odpowiedzi nie działają dla mnie. Rozwiązaniem było ręczne usunięcie folderu bin i obj.

Znalazłem ten problem, ale był najbardziej podobny do tego, co wyjaśnił @Kirk i przepisywania adresu URL.

W moim przypadku ktoś sprawdził tę zmianę w pliku web.config dla projektu MVC:

<system.webServer>
    <security>
        <requestFiltering>
            <fileExtensions>
                <add fileExtension=".aspx" allowed="false" />
            </fileExtensions>
        </requestFiltering>
    </security>
</system.webServer>

Ponieważ rozszerzenia plików .aspx nie były dozwolone na serwerze sieci Web, /debugattach.aspxadres URL został odrzucony, co uniemożliwiło uruchomienie debugera. Po usunięciu tej konfiguracji znowu zadziałało.

Miałem ten sam problem, gdy tworzyłem aplikację w Visual Studio, a następnie we właściwościach utworzono katalog wirtualny do użytku z lokalnymi usługami IIS. Jeśli ktoś ma ten błąd, to dlatego, że VS tworzy aplikację w niewłaściwej puli aplikacji, czyli w puli aplikacji, która nie odpowiada Twoim potrzebom.
W takim przypadku przejdź do Menedżera IIS, wybierz aplikację, przejdź do ustawień podstawowych i zmień AppPool dla aplikacji i gotowe.

Niedawno dostałem ten sam błąd iw moim przypadku okazało się, że są zduplikowane typy MIME. Niedawno dodałem dwa, które początkowo nie pojawiły się na liście. IIS pozwoliło mi je dodać i dopiero wtedy, gdy zdecydowałem się ponownie sprawdzić typy MIME dla witryny w ramach mojego procesu diagnostycznego, również dostałem błąd w IIS. Odwołał się do duplikatów w pliku web.config. Kiedy wróciłem do pliku web.config, zauważyłem, że dodano nową sekcję o nazwie, która zawiera dwa ostatnio dodane typy MIME. Usunięto tę sekcję i życie znów jest dobre! Mając nadzieję, że może to pomóc innym, którym nie udało się rozwiązać problemu za pomocą żadnej z innych sugestii.