Что такое debugattach.aspx и почему сервер не может его найти?

На основании этой старой публикации, DebugAttach.aspx реализуется обработчиком HTTP System.Web.HttpDebugHandler. На самом деле я нигде не видел ссылок на этот обработчик в IIS7 - возможно, эта реализация была объединена с каким-то другим обработчиком в будущем. Хотя определенно какой-то обработчик. Когда он работает, вы видите 200 (успешных) сообщений в журналах.

У меня была одна и та же проблема двумя разными способами, когда отладка F5 не удалась в VS2010 из-за проблемы с обработчиком отладки. Используя журналы отслеживания неудачных запросов IIS, я смог увидеть случаи, когда модули IIS мешали работе. В одном случае UrlScan.dll блокировал команду DEBUG. В другом случае перенаправление с HTTP на HTTPS приводило к тому, что обработчик отладки возвращал 302. В обоих случаях VS выдал похожий диалог.

В любом случае, хитрость здесь, похоже, заключается в том, чтобы выяснить, как можно заблокировать запрос DEBUG к этому URL-адресу.

В моем случае я создал пустое веб-приложение с VS2017 в Windows 10. Когда я снял флажок для отладчика ASP.NET в разделе «Настройки проекта» -> «Веб», проблема исчезла. До этого я пробовал почти все предложения, чтобы решить проблему.

Из соображений производительности мы удалили все обработчики из элемента <system.webServer> элемента web.config нашего проекта MVC 5, кроме StaticFile и ExtensionlessUrlHandler-Integrated-4.0, а затем начали получать эту ошибку при отладке из Visual Studio.

После некоторого исследования мы обнаружили, что при обычном использовании любой модуль, обрабатывающий этот запрос, просто возвращает ошибку HTTP 401 (несанкционированный доступ). Мне не удалось выяснить, что именно это за модуль, но я смог найти ответственный класс: System.Web.HttpDebugHandler.

Поэтому мы добавили в наши обработчики web.config следующую строку:

<add name="DebugAttachHandler" path="DebugAttach.aspx" verb="DEBUG"
    type="System.Web.HttpDebugHandler" resourceType="Unspecified" requireAccess="Script"
    preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" />

При попадании по этому URL-адресу IIS выдает ошибку 401, как и при включении всех обработчиков, поэтому Visual Studio снова счастлива.

См. также: https://developercommunity.visualstudio.com/content/problem/464980/unable-to-start-debugging-a-web-project-when-vs-ge.html

Я просто столкнулся с этим. Я отключил параметр Разрешить неуказанные расширения имен файлов в разделе Фильтрация запросов на своем локальном сервере IIS (чтобы соответствовать нашим усиленным настройкам безопасности в других средах). Оказывается, .aspx блокировался. Я снова включил настройку и смог подключиться с помощью отладчика. Поэтому я снова отключил его и добавил разрешение на уровне сайта для .aspx, и я снова могу подключиться к отладчику.

Мне также любопытно, почему отладчик ищет debugattach.aspx и терпит неудачу с этой ошибкой. Тем более, что мое приложение - MVC, и мне не нужно обслуживать .aspx.

У меня была карта сценариев с подстановочными знаками для версии .NET 4 aspnet_isapi.dll, которая вызывала это. Я смог изменить сопоставление сценария, чтобы игнорировать глагол DEBUG (используя только глаголы, необходимые для моего приложения), и это позволило VS автоматически подключаться.

Сказав это, я в конечном итоге использовал либо веб-сервер разработки VS, либо IIS Express, чтобы заставить мой сайт работать на компьютере с XP, потому что IIS 5.1 не понравилось сочетание карты сценариев с подстановочными знаками и маршрутизации ASP.NET.

Если вы используете VS2010 или более позднюю версию и установили .Net 4.x или более позднюю версию, попробуйте переименовать подкаталог «v3.0» (например, «переименовать C:\Windows\Microsoft.Net\Framework\v3.0 v3.0). .ORIGINAL"), перезагрузите компьютер и повторите попытку отладки в Visual Studio.

Это работало как кровавое очарование для меня, но ваш пробег может варьироваться в зависимости от того, какую разработку вы делаете.

Я использую Visual Studio 2012 уже две недели, и я серьезно не могу поверить, насколько все быстро (опять же!). Запуск отладчика по F5 теперь мгновенный, и остановка сеанса отладки тоже мгновенная. Всякие глючные и лаги в поведении прекратились, и пока я не увидел ни одного побочного эффекта.

Решение, которое работает для меня, состояло в том, чтобы перезапустить VStudio в режиме «Запуск от имени администратора».

Недавно я столкнулся с этой проблемой с файлом debugattach.aspx. Для меня это началось с сообщения об ошибке при попытке отладки приложения ASP.NET через VS 2017. Проведя два дня, следуя всем предложениям в сети, я наконец наткнулся на эту вещь debugattach.aspx. Я тоже хотел знать, что это такое и почему IIS возвращал ответ 403-Forbidden на запросы об этом.

Короче говоря, это случилось со мной, потому что приложение, которое я хотел отладить, оказалось в виртуальном каталоге другого веб-приложения. Я должен был убедиться, что флаг <compilation debug="true" был установлен в «родительском» приложении, хотя меня не интересовала его отладка.

Головокружение в конце. Надеюсь, это поможет кому-то еще, кто пытается отследить проблемы, связанные с debugattach.aspx.

Добавьте <compilation debug="true"> в свой Web.config.