Разное

Debug true: Включение отладки для приложений ASP.NET — Visual Studio (Windows)

06.05.2023

Включение отладки для приложений ASP.NET — Visual Studio (Windows)

  • Статья
  • Чтение занимает 8 мин

Область применения:Visual StudioVisual Studio для Mac Visual Studio Code

Вы можете выполнять отладку приложений ASP.NET и ASP.NET Core в Visual Studio. Точный процесс зависит от типа приложения (ASP.NET или ASP.NET Core) и от того, выполняется ли он в IIS Express или на локальном сервере IIS.

Примечание

Приведенные далее шаги и параметры относятся только к отладке приложений на локальном сервере. При отладке приложений на удаленном сервере IIS используется подключение к процессу, а эти параметры игнорируются.

Дополнительные сведения и инструкции по удаленной отладке приложений ASP.NET в IIS см. в разделе Удаленная отладка ASP.NET на компьютере IIS или Удаленная отладка ASP.NET Core на удаленном компьютере IIS.

Встроенный сервер IIS Express входит в состав Visual Studio. IIS Express является сервером отладки по умолчанию для проектов ASP.NET и ASP.NET Core. Он уже предварительно настроен. Это самый простой способ отладки, идеально подходящий для первоначальной отладки и тестирования.

Для ASP.NET Core также можно выполнить отладку на веб-сервере Kestrel.

Можно также выполнять отладку приложения ASP.NET или ASP.NET Core на локальном сервере IIS (версии 8.0 или более поздней), настроенном для запуска этого приложения. Для отладки на локальном сервере IIS необходимо выполнить следующие требования.

  • Если она не установлена, установите рабочую нагрузку ASP.NET и веб-разработка. (Перезапустите Visual Studio Installer, выберите Изменить и добавьте эту рабочую нагрузку. )

  • Запустите Visual Studio от имени администратора.

  • Установить и правильно настроить IIS, указав соответствующие версии ASP.NET и (или) ASP.NET Core. Дополнительные сведения об использовании IIS с ASP.NET Core см. в статье Размещение ASP.NET Core в Windows со службами IIS. Инструкции для ASP.NET см. в статье Установка служб IIS и модулей ASP.NET.

  • Убедиться, что приложение работает в IIS без ошибок.

Отладка приложений ASP.NET

Сервер IIS Express используется по умолчанию и уже предварительно настроен. Если вы хотите выполнять отладку на локальном сервере IIS, убедитесь, что выполняются требования для отладки на локальном сервере IIS.

  1. Выберите проект ASP.NET в Обозревателе решений Visual Studio, щелкните значок Свойства и нажмите сочетание клавиш ALT+ВВОД либо щелкните проект правой кнопкой мыши и выберите пункт

    Свойства.

  2. Перейдите на вкладку Интернет.

  3. В области Свойства в разделе Серверы выполните следующее.

    • Для сервера IIS Express выберите IIS Express в раскрывающемся списке.
    • Для локального сервера IIS:
      1. в раскрывающемся списке выберите Локальный сервер IIS;
      2. рядом с полем URL-адрес проекта установите флажок Создать виртуальный каталог, если вы еще не настроили приложение в службах IIS.

  4. В разделе Отладчики выберите ASP.NET.

  5. Выберите Файл>Сохранить выбранные элементы или нажмите сочетание клавиш CTRL+S, чтобы сохранить изменения.

  6. Для отладки приложения установите точки останова в некоторых местах кода проекта. На панели инструментов Visual Studio убедитесь, что для конфигурации задано значение Отладка, и нужный вам браузер отображается в поле эмулятора IIS Express (<имя браузера>) или Локальный сервер IIS (<имя браузера>) в поле эмулятора.

  7. Чтобы начать отладку, на панели инструментов выберите IIS Express (<имя браузера>) или Локальный сервер IIS (<имя браузера>), а затем выберите Начать отладку в меню Отладка или нажмите клавишу F5. Отладчик приостанавливает выполнение в точках останова. Если отладчик не может попасть в точки останова, см. раздел Устранение неполадок при отладке.

Отладка приложений ASP.NET Core

Сервер IIS Express используется по умолчанию и уже предварительно настроен. Если вы выполняете отладку на локальном сервере IIS, а не на IIS Express, убедитесь, что выполняются требования для отладки на локальном сервере IIS. Также имеется профиль по умолчанию, основанный на имени проекта, который настроен для веб-сервера Kestrel.

  1. Выберите проект ASP.NET Core в Обозревателе решений Visual Studio, щелкните значок Свойства и нажмите сочетание клавиш ALT+ВВОД либо щелкните проект правой кнопкой мыши и выберите пункт Свойства.

  2. Перейдите на вкладку Отладка и щелкните ссылку, чтобы открыть Пользовательский интерфейс профилей запуска отладки

    .

    Представленный пользовательский интерфейс соответствует параметрам в файле launchSettings.json проекта. Дополнительные сведения об этом файле см. в разделе «Разработка и launchSettings.json» из статьи Использование нескольких сред в ASP.NET Core.

  3. Выберите профиль, который необходимо настроить для отладки.

    • Для сервера IIS Express выберите IIS Express в раскрывающемся списке.
    • Для Kestrel выберите профиль с таким же именем, как и у проекта.
    • Для локальных служб IIS выберите Создать и создайте профиль IIS.

  4. Убедитесь, что флажок Запуск браузера установлен.

  5. Убедитесь, что URL-адрес, URL-адрес приложения и URL-адрес SSL приложения указаны правильно.

    URL-адрес задает расположение узла для .NET или .NET Core. Если профиль назван как проект (то есть свойство commandName в launchSettings.json имеет значение Project), то сервер Kestrel ожидает передачи данных по указанному порту. Для профиля IIS значение обычно совпадает с URL-адресом приложения. Дополнительные сведения см. в разделе Настройка проекта в части «Профиль запуска служб IIS».

    URL-адрес приложения и URL-адрес SSL приложения указывают URL-адрес(а) приложения. Если профиль назван по проекту, это свойство задает URL-адреса сервера Kestrel (обычно https://localhost:5001 и http://localhost:5000. ). Для IIS Express URL-адрес SSL приложения — обычно http://localhost:44334..

  6. В разделе Переменные среды убедитесь, что параметр ASPNETCORE_ENVIRONMENT существует и имеет значение Разработка. Если это не так, добавьте переменную.

    Дополнительные сведения о переменных среды см. в разделе Среды.

  7. Для отладки приложения установите точки останова в некоторых местах кода проекта. На панели инструментов Visual Studio убедитесь, что в качестве параметра конфигурации задано значение Отладка.

  8. Чтобы начать отладку, выберите имя профиля на панели инструментов, например <имя профиля проекта>, IIS Express или <имя профиля IIS> на панели инструментов, выберите Начать отладку выберите Отладка или нажмите клавишу F5. Отладчик приостанавливает выполнение в точках останова. Если отладчик не может попасть в точки останова, см. раздел Устранение неполадок при отладке.

Отладка приложений ASP.NET Core

Сервер IIS Express используется по умолчанию и уже предварительно настроен. Если вы хотите выполнять отладку на локальном сервере IIS, убедитесь, что выполняются требования для отладки на локальном сервере IIS.

  1. Выберите проект ASP.NET Core в Обозревателе решений Visual Studio, щелкните значок Свойства и нажмите сочетание клавиш ALT+ВВОД либо щелкните проект правой кнопкой мыши и выберите пункт

    Свойства.

  2. Выберите вкладку Отладка.

  3. В области Свойства рядом с полем Профиль выполните следующее.

    • Для сервера IIS Express выберите IIS Express в раскрывающемся списке.
    • Для локального сервера IIS выберите в раскрывающемся списке имя приложения или нажмите Создать, создайте новое имя профиля и нажмите кнопку ОК.

  4. В раскрывающемся списке рядом с полем Запуск выберите IIS Express или IIS.

  5. Убедитесь, что флажок Запуск браузера установлен.

  6. В разделе Переменные среды убедитесь, что параметр ASPNETCORE_ENVIRONMENT существует и имеет значение Разработка. Если этот параметр отсутствует, нажмите кнопку Добавить и добавьте его.

  7. Выберите Файл>Сохранить выбранные элементы или нажмите сочетание клавиш CTRL+S, чтобы сохранить изменения.

  8. Для отладки приложения установите точки останова в некоторых местах кода проекта. В панели инструментов Visual Studio убедитесь, что для конфигурации задано значение Отладка, а в поле эмулятора указано IIS Express или имя нового профиля IIS.

  9. Чтобы начать отладку, на панели инструментов выберите IIS Express или <Имя профиля IIS>, а затем выберите Начать отладку в меню Отладка или нажмите клавишу F5. Отладчик приостанавливает выполнение в точках останова. Если отладчик не может попасть в точки останова, см. раздел Устранение неполадок при отладке.

Устранение неполадок отладки

Если при отладке на локальном сервере IIS не удается достичь точки останова, выполните следующие шаги для устранения неполадок.

  1. Запустите веб-приложение из IIS и убедитесь, что оно работает правильно. Оставьте веб-приложение работать.

  2. В Visual Studio выберите Отладка > Подключение к процессу или нажмите клавиши CTRL+ALT+P, а затем подключитесь к процессу ASP.NET или ASP.NET Core (обычноw3wp.exe или dotnet.exe). Дополнительные сведения см. в разделах Подключение к процессу и Поиск имени процесса ASP.NET.

Если вы можете подключиться и попасть в точку останова путем выбора пункта Подключиться к процессу, но не путем выбора Отладка>Начать отладку или нажатия клавиши F5, скорее всего, в свойствах проекта неправильно задан параметр. Если вы используете файл HOSTS, также проверьте правильность его настройки.

Настройка отладки в файле web.config

В проектах ASP.NET по умолчанию имеются файлы web.config, которые содержат сведения о конфигурации и запуске, в том числе параметры отладки. Файлы web.config должны быть правильно настроены для отладки. Обновить файлы web.config можно с помощью параметров Свойства, которые рассматривались в предыдущих разделах, но можно также настроить эти файлы вручную.

Примечание

В проектах ASP.NET Core изначально нет файлов web.config, но для настройки сведений о конфигурации и запуске можно использовать файлы appsettings.json и launchSettings.json. При развертывании приложения в этом проекте создается файл (или файлы) web.config, но обычно в нем отсутствуют сведения об отладке.

Совет

Процесс развертывания может обновить параметры в web.config, поэтому, прежде чем приступить к отладке, проверьте, настроена ли отладка в файле web. config.

Чтобы вручную настроить отладку в файле web.config, выполните следующие действия.

  1. В Visual Studio откройте файл web.config проекта ASP.NET.

  2. Файл web.config — это XML-файл, поэтому он содержит вложенные разделы, помеченные тегами. Найдите раздел configuration/system.web/compilation. (Если элемент compilation не существует, создайте его.)

  3. Убедитесь, что атрибут debug в элементе compilation имеет значение true. (Если в элементе compilation отсутствует атрибут debug, добавьте его и установите для него значение true.)

    Если вместо сервера IIS Express по умолчанию вы используете локальный сервер IIS, убедитесь, что значение атрибута targetFramework в элементе compilation соответствует платформе на сервере IIS.

    Элемент compilation в файле web. config должен выглядеть, как показано в следующем примере:

    Примечание

    Этот пример представляет часть файла web.config. Обычно в элементах configuration и system.web имеются дополнительные разделы XML, а элемент compilation может также содержать другие атрибуты и элементы.

    <configuration>
   ...
   <system.web>
       <compilation  debug="true"  targetFramework="4.6.1" ... >
          ...
       </compilation>
   </system.web>
</configuration>

ASP.NET автоматически обнаруживает изменения в файлах web.config и применяет новые параметры конфигурации. Не нужно перезагружать компьютер или сервер IIS, чтобы изменения вступили в силу.

Веб-сайт может содержать несколько виртуальных каталогов и подкаталогов, и в каждом из них могут быть файлы web.config. Приложения ASP.NET наследуют параметры конфигурации из файлов web.config, находящихся на более высоких уровнях в пути URL-адреса. Параметры иерархических файлов web.config применяются ко всем приложениям на более низком уровне в иерархической структуре. Настройка другой конфигурации в файле web.config, находящемся ниже в иерархической структуре, переопределяет параметры, заданные в файле на более высоком уровне.

Например, если задать debug="true" в файле www.microsoft.com/aaa/web.config, все приложения в папке aaa и во всех вложенных папках aaa наследуют этот параметр, кроме тех приложений, у которых имеется собственный файл web.config.

Важно!

Режим отладки значительно снижает производительность приложения. При развертывании рабочего приложения или проведении измерений производительности задайте debug="false" в web.config и укажите сборку выпуска.

См. также

  • Отладка ASP.NET: системные требования
  • Практическое руководство. Запуск рабочего процесса в учетной записи пользователя
  • Практическое руководство. Поиск имени процесса ASP.NET
  • Отладка развернутых веб-приложений
  • Практическое руководство. Отладка исключений ASP.NET
  • Отладка веб-приложений: ошибки и устранение неполадок

asp.net — debug=true в web.config = ПЛОХАЯ вещь?

спросил

Изменено 6 месяцев назад

Просмотрено 69 тысяч раз

Мы наблюдаем большое количество ошибок фрагментации виртуальной памяти и нехватки памяти, а затем она достигает предела в 3 ГБ.

Для отладки компиляции установлено значение true в web.config, но я получаю разные ответы от всех, кого я спрашиваю, вызывает ли отладка значение true, чтобы каждый aspx компилировался в случайные области ОЗУ, таким образом фрагментируя этот ОЗУ и в конечном итоге вызывая проблемы с памятью ?

  • asp. net
  • web-config

Скотт Гатри (менеджер группы разработчиков ASP.NET) написал об этом интересный пост.

Наиболее важные моменты, почему не следует оставлять debug="true" :

  1. Компиляция страниц ASP.NET занимает больше времени (поскольку некоторые пакетные оптимизации отключены)
  2. Код может выполняться медленнее (поскольку включены некоторые дополнительные пути отладки)
  3. Во время выполнения приложение использует гораздо больше памяти
  4. Сценарии и изображения, загруженные из обработчика WebResources.axd, не кэшируются браузером, что приводит к большему количеству запросов между клиент и сервер

Он также упоминает флаг > в файле machine.config, который позволяет глобально переопределить флаг debug="true" всех приложений, работающих на машине (например, на производственном сервере). .

Обновление : развертывание веб-приложений с debug="true" по-прежнему плохой, как вы можете прочитать в недавнем сообщении в блоге Скотта Хансельмана:

Вот почему debug="true" — это плохо. Серьезно, мы не шутим.

  • Преодолевает тайм-аут выполнения запроса, делая его фактически бесконечным
  • Отключает оптимизацию страницы и JIT-компилятора
  • В версии 1.1 приводит к чрезмерному использованию памяти средой CLR для отслеживания отладочной информации.
  • В версии 1.1 отключает пакетную компиляцию динамических страниц, что приводит к созданию 1 сборки на странице.
  • Для кода VB.NET приводит к чрезмерному использованию WeakReferences (используется для редактирования и продолжения поддержки).

Важное примечание: вопреки тому, что иногда считают, установка retail="true" в элементе не является прямым противоядием от имея отладку = "истина"!

1

Флаг отладки должен быть установлен в значение false в файле web.config, если вам действительно не нужно отлаживать приложение.

Запуск в режиме отладки может несколько увеличить использование памяти, но вряд ли это приведет к таким серьезным проблемам, о которых вы говорите. Тем не менее, вы должны установить для него значение false, чтобы устранить эффект, который он имеет, и посмотреть, заметите ли вы какие-либо улучшения.

При запуске в режиме отладки сборка мусора работает иначе. Время жизни переменных расширяется от их фактического использования до области действия переменной (чтобы можно было показать значение в отладчике). Это заставляет некоторые объекты жить дольше, прежде чем они будут удалены сборщиком мусора.

Компилятор не оптимизирует код при компиляции в режиме отладки, а также добавлено несколько дополнительных инструкций nop , чтобы в каждой строке кода была хотя бы одна инструкция, где можно поставить точку останова.

Создание исключения в режиме отладки занимает значительно больше времени. (Однако обычно код не должен вызывать исключения так часто.)

AFAIK "debug = true" не вызывает упомянутую вами ситуацию.

Я столкнулся с той же проблемой с приложением ASP.NET, которое создавало изображения на лету.

так что я думаю у вас проблема с не утилизируемыми ресурсами.

Если вы развертываете файлы aspx с файлами кода программной части на сервере. Он будет скомпилирован один раз, когда запрос придет на aspx. затем он будет храниться в кеше до тех пор, пока файл не изменится.

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

Если на вашем сайте много файлов, меня больше беспокоит disk io в папке временных файлов asp.net.

Пара вопросов...

  1. У вас много файлов в App_Code?
  2. Вы разрешаете обновлять сайт или публикуете его?
  3. Если да, сайт часто обновляется или выполняется процесс развертывания?
  4. Какая аппаратная конфигурация?

Почему бы не использовать несколько конфигураций?

Web.Debug.Config — включена отладка Web.UAT.Config — на ваше усмотрение Web.Release.Config — отключить отладку

Таким образом, вы можете свести к минимуму регрессионные ошибки конфигурации, например, когда разработчик проверяет web. config с помощью debug="true"

В производственных системах всегда устанавливайте Debug=false. Как следует из флага, для него следует устанавливать значение true только при отладке системы разработки.

Этот флаг не имеет ничего общего с вашей проблемой фрагментации памяти.

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя адрес электронной почты и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

python.

Каковы функциональные различия между DEBUG = True и False в Django?

спросил

Изменено 4 года, 11 месяцев назад

Просмотрено 14 тысяч раз

Каковы функциональные различия между переключением параметра DEBUG в файле settings.py приложения Django?

Сначала я предположил, что DEBUG=True просто включил возможность ведения журнала Django и промежуточное программное обеспечение для отчетов об ошибках, но теперь я понимаю, что это было наивно с моей стороны. Понимание того, как внутренние системы Django работают по-разному при двух логических параметрах, помогает формировать гипотезы при работе с трудными для отладки простыми ошибками статуса 500

  • питон
  • джанго

2

Одним из основных преимуществ DEBUG=True являются подробные страницы ошибок. Django предоставляет подробную трассировку стека того, что пошло не так. Что очень полезно при отладке. По сути, в режиме DEBUG django запоминает каждый выполняемый SQL-запрос (что опять же делает его совершенно непригодным для производства).

Кроме того, если DEBUG=True, проверка узла отключена. Другими словами, если DEBUG=False, необходимо установить ALLOWED_HOSTS.

1

  1. DEBUG=True , если есть ошибка, страница покажет подробности ошибки.

  2. , если DEBUG=False , ALLOWED_HOSTS из settings.py будет работать, вы должны внимательно настроить его.

  3. media и static не будут предоставлять доступ для DEBUG=False , вы должны предоставить их с помощью веб-сервера, например Nginx или Apache .

0

Начиная с Django 1.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *