Не вдається запустити налагодження на веб-сервері. Не вдалося запустити налагодження ASP.NET VS 2010, II7, Win 7 x64

Я запускаю Visual Studio 2010 (як адміністратор), IIS 7 в Windows 7 x64. Я в змозі запустити веб-сайт ASP.NET в IIS 7, не налагоджуючи це просто добре, але коли я натискаю F5 для його налагодження, я отримую:

Не вдається запустити налагодження на веб-сервері. Не вдалося запустити налагодження ASP.NET. Додаткову інформацію можна отримати, запустивши проект без налагодження.

На жаль, посилання на допомогу мені не дуже допомагає і призводить до біса великого дерева речей.

Я перевірив наступне:

• Вимоги безпеки - я не пам'ятаю, щоб раніше робити щось особливе. Процес роботи в IIS7 - це w3wp.exe. У ньому йдеться про те, що якщо він працює як ASPNET або NETWORK SERVICE, я повинен мати права адміністратора для його налагодження. Як дізнатись, чи потрібно мені щось тут змінити?

• Сторінки власності веб-сайту> Параметри запуску> Налагоджувачі> ASP.NET перевірено. Використовувати користувальницький сервер встановлюється за URL-адресою сайту (що працює нормально без налагодження).

• Налагодження ввімкнено в web.config.

• Програма використовує ASP.NET 3.5 (я хочу перейти на 4.0 з часом, але я маю певну міграцію для вирішення).

• Пул додатків: Класифікація .NET AppPool (також випробуваний DefaultAppPool).

Будь-які ідеї, де я можу перевірити наступне?

Невже це не повинно бути таким важким, щоб встановити IIS, VS, створити веб-сайт і почати його тестувати?

Заздалегідь спасибі.

Спробуйте перейти до IIS та перевірте, чи не запускається пул додатків, який ви використовуєте. Ви багато разів випустите помилку, яка закриває пул додатків. Вам просто потрібно клацнути правою кнопкою миші та кнопку "Пуск", і ви повинні бути хорошими.

Виявляється, винуватцем був модуль перезапису URL-адреси IIS . Я визначив правило, на яке переадресовували дзвінки Default.aspx (яке було встановлено як початкову сторінку веб-сайту ) до кореня сайту, щоб я міг мати канонічну домашню URL-адресу. Однак, мабуть, у В. С. була проблема з цим і заплуталася. Ця проблема не сталася, коли я використовував Helicon ISAPI_Rewrite, тому мені навіть не спало на думку перевірити.

Я в кінцевому підсумку створив цілком новий веб-сайт з нуля та переносить проекти / файли потроху в своє рішення та відновлює свій web.config, поки не знайшов цього! Ну, принаймні зараз у мене трохи чистіший сайт, що використовує .NET 4.0 (поки що, сподіваюся, я не зіткнуся з жодними стінами) - але який біль!

Visual Studio при запуску (чомусь) намагатиметься отримати доступ до URL-адреси:

/debugattach.aspx

Якщо у вас є правило перезапису, яке перенаправляє (або іншим чином ловить), скажімо, .aspxфайли, ще десь, тоді ви отримаєте цю помилку. Рішення полягає в тому, щоб додати цей розділ в початок вашого web.config«сек <system.webServer>/<rewrite>/<rules>розділу:

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

Це дозволить переконатися в цьому конкретному запиті, нічого не робити , і, головне, зупинити виконання, щоб жодне з ваших інших правил не запустилося. Це надійне рішення, тому сміливо зберігайте це у своєму конфігураційному файлі для виробництва.

На користь інших, у моєму випадку я сконфігурував пул додатків для використання своїх облікових даних Windows для доступу до спільної мережі ресурсів. З моменту налагодження рішення останнім часом я скинув пароль Windows. Змінено пароль, що зберігається в пулі додатків і bada bing.

Якщо для параметра Identity ApplicationPool встановлено спеціальний обліковий запис і пароль комп'ютера змінено, вам доведеться оновити свій пароль

Для мого сценарію це було зміни в розділі httpErrors в web.config, встановивши його так:

<httpErrors mode="Custom"> 

викликало проблему "Неможливо почати налагодження на веб-сервері". Повернення його до попереднього значення "DetailedLocalOnly" виправило проблему. Копаючи трохи глибше, я виявив, що саме ця настройка помилки 401 була причиною цього:

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

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

Я досі не маю уявлення, чому це відбувається.

Поставте пул додатків для перевірки. якщо він зупинений. перезапустіть його.

У цій же проблемі була спроба налагодити модуль DNN (Dot Net Nuke). Виявилося, ви повинні мати налагодження компіляції = "true":

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

у вашому web.config. За замовчуванням це неправда в DNN. Оригінальне джерело тут: http://www.dnnsoftware.com/forums/forumid/111/postid/189880/scope/posts

У мене точно така ж проблема після впровадження модуля переписання.

Якщо я видаляю записи для перезапису з мого файлу web.config, налагодження справно працює.

Щоб обійти це, я просто прокоментував теги для перезапису під час налагодження, як це ...

<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>

Потім видаляю коментарі після налагодження.

Повинно бути помилкою у візуальній студії 2010 року.

Я отримав таку ж помилку, оскільки пул застосунків був зупинений у IIS. Після запуску пулу додатків проблема була вирішена.

Ось що я зробив, щоб очистити зазначену вами помилку. Знайдіть веб-папку програми у файловій системі, перейдіть до Властивості => Захист, натисніть кнопку Додатково, потім перейдіть на вкладку Власник , натисніть кнопку Редагувати та змініть власника (з правильними дозволами) папки та встановіть прапорець " Repalce власник на підконтейнери та об'єкти ". Клацніть « Застосувати », і тоді я займався бізнесом (міг налагоджувати).

Сподіваюся, це працює для когось іншого.

Щойно нарешті виправили це для свого єдиного рішення, яке мало це. Два проекти в рішенні були розміщені як сайти в IIS. Я ввійшов і ввімкнув себе під назвою ASP.Net, видавши себе за автентифікацію для обох проектів ... та VIOLA! НАСАЛЬНО, більше немає цієї прикрої помилки!

Я отримував те саме повідомлення про помилку в VS 2012, але не працював як Адміністратор. Коли я запустив додаток як адміністратор, я отримав інше і трохи корисніше повідомлення (яке я зміг зрозуміти). HTH

Якщо App Pool має проблеми з перезавантаженням або просто не хоче перезапустити, переконайтесь, що Windows оновила нещодавнє оновлення на ASP.NET v4.0 або іншому пулі додатків. Це те, що відбувається в моєму випадку. Я просто перезапустив комп’ютер, потім перезапустив ASP.NET v4.0 App Pool і все знову працювало!

Ден,

Окрім пропозицій Аарона, спробуйте наступне

• Переконайтеся, що на вашому веб-сайті IIS вибрано інтегровану автентифікацію Windows
• Чи можете ви налагодити використання Cassini замість IIS?

Була така ж проблема з Windows 10 при включенні всіх функцій вікон IIS. Підключено до Windows 8.1 і знову виникло проблему. Корінь містив назву веб-сайту " http: //MySite.local " (не стосується версії ОС).

І рішення просте

• Редагувати файл хостів у %SystemRoot%\System32\drivers\etc\

• Додати рядок із прив’язкою ip: 127.0.0.1 MySite.local

У мене ця помилка виникла сьогодні через дефект коду, який надсилав величезну кількість разів назад, через що IIS заповнювались запитами. Це по суті заблокувало IIS, і тому, коли я намагався налагодити, він "вичерпався", намагаючись запустити налагоджувач. Я просто перезапустив IIS, що зайняло кілька хвилин, і це вирішило проблему.

Я впевнений, що бажаю, щоб ця помилка була менш загальною, схоже, існує кілька різних способів її виправити.

У мене була однакова проблема в Visual Studio 2012 та 2013 на Windows 8.1. Для мене виправленням було додати автентифікацію Windows до IIS за допомогою "Увімкнення та вимкнення функцій Windows"

Будьте впевнені, що на базі додатків вашого веб-сайту використовується правильна рамкова версія . Я отримав помилку "Неможливо почати налагодження" на сайті ASP.Net 2005. Невірно було використано DefaultAppPool для Windows 7 (для якого я вважаю, що використовував. Net Framework 4). Я створив новий пул додатків на основі .Net Framework 2 і призначив його проблемному веб-сайту. Після цього налагодження спрацювало чудово.

Перевірте, чи ваш веб-сайт на IIS не зупиняється.

Я виправив це, щоб мій веб-сайт запустився. : D

У мене була ця проблема і врешті-решт зрозумів, що я ASP.net не зареєстрований належним чином у IIS. Це може статися, коли сервер IIS встановлений перед Visual Studio. Щоб виправити цю проблему, використовуйте команду aspnet_regiis -i Детальну інформацію можна знайти за посиланням

мали те саме питання. Якщо у вас на сервері IIS встановлено сертифікат SSL і ви намагаєтеся налагодити його від Visual Studio, вам потрібно встановити свою програму на IIS, щоб ігнорувати сертифікат.

У мене була та сама проблема, і я виявив, що це викликано, тому що у мене був помилково введений символ у моєму Web.configкінцевому тезі. Мій Web.configвиглядало як це право в кінці: </section>h. Після завершального тегу "h" був додатковим символом.

видаліть жало так: targetFramework = "4.0" в web.config або змініть AppPool на відповідну версію рамки.

Видалення розширення IIS UrlScan вирішило проблему для мене.

Я зіткнувся з тією ж проблемою, але це було на власному сервері веб-розробки Visual studios, а не на IIS. Обхід полягає в тому, щоб зняти прапорець на вкладці Веб у розділі властивостей проекту, Застосувати параметри сервера до всіх користувачів (зберігати у файлі проекту.) це заощадить чийсь цінний час.

У мене була така ж проблема. Усі відповіді вище для мене не спрацювали. Рішенням було видалити папку bin та obj вручну.

Я також знайшов цю проблему, але вона була найбільш схожа на те, що пояснив @Kirk та перезапис URL-адрес.

У моєму випадку хтось перевірив цю зміну у файлі web.config для проекту MVC:

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

Оскільки розширення файлів .aspx не були дозволені на веб-сервері, /debugattach.aspxURL-адресу було відхилено, не дозволяючи налагоджувачу працювати. Як тільки я видалив цю конфігурацію, вона знову працювала.

У мене була така ж проблема, коли я створював додаток у Visual Studio, а потім у властивостях створював віртуальний каталог для використання з локальним IIS. Якщо хтось має цю помилку, це тому, що VS створює додаток під неправильним AppPool, тобто під AppPool, який не відповідає вашим потребам.
Якщо це так, перейдіть до менеджера IIS, виберіть додаток, перейдіть до основних налаштувань та змініть AppPool для додатка, і ви готові піти.

Я отримав цю саму помилку нещодавно, і в моєму випадку виявилося, що існували повторювані типи MIME. Нещодавно я додав два, які спочатку не відображались у списку. IIS дозволив мені додати їх, і лише тоді, коли я вирішив перевірити типи MIME для сайту ще раз, як частину діагностичного процесу, я також отримав помилку в IIS. Він посилається на дублікати в web.config. Одного разу я повернувся до файлу web.config, я помітив, що був доданий новий розділ, який називається, який включає два нещодавно додані MIME типи. Видалено цей розділ і життя знову добре! Сподіваючись, що це може допомогти іншим, хто не зумів вирішити проблему жодною з інших пропозицій.