Я написал это как одно целое ранее как для Node-Inspector, так и для NTVS для отладки приложений Node.Js в IIS (с IISNode). Статья была слишком большой, поэтому я решил разделить ее на две части. Также теперь я предвзят, отладка Node-Inspector лучше, не читайте часть NTVS, если вам это не особо интересно.

ЧАСТЬ 1: Настройка отладки Node-Inspector

Я бы порекомендовал прочитать часть 1, она содержит важную информацию о настройке IIS для Node.Js (и, конечно, о готовности к отладке).

В предыдущей статье я указал причины, по которым отладка Node-Inspector стала моей любимой. Тем не менее, если вы хотите остаться в Visual Studio с помощью инструментов Node.Js для Visual Studio, вот что вам нужно сделать, чтобы отладить работающее приложение на сервере.

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

Два файла в корневой папке проекта и один файл в папке bin важны для отладки. IISNode.ymlи web.config находятся под root и Microsoft.NodejsTools.WebRole .dll находится в папке /bin.

Создав образец/тестовый проект в Visual Studio, вы можете получить пример web.config и этот DLL-файл.

Файл ⇒ Создать ⇒ Проект ⇒ Шаблоны ⇒ Javascript ⇒ Node.js ⇒ Базовое приложение Azure Node.js Express 4

Вам нужно будет загрузить Microsoft.NodejsTools.WebRole.dll на свой сервер (помните папку /bin) перед запуском отладчика из вашего VS.

Развертывание в Azure можно выполнить, не выходя из VS, но когда вы работаете напрямую с IIS, вы, вероятно, будете выполнять загрузку по FTP. Так что не путайте с файлом Web.Debug.config, созданным с вашим тестовым проектом. Как следует из названия шаблона проекта, этот шаблон ориентирован на Azure, и преобразования XDT происходят (например, параметры в Web.Debug.config перезаписывают параметры Web.config) непосредственно перед развертыванием приложения с помощью VS.

При развертывании по FTP это преобразование XDT не может произойти автоматически, поэтому вам придется вносить изменения в файл Web.config (и возвращаться обратно после завершения отладки) вручную.

1.IISNode.yml . Теоретически Web.config также имеет эти настройки, как показано ниже. Однако у меня возникли проблемы с подключением отладчика к серверу в моих попытках, поэтому просто чтобы убедиться, что я создал файл IISNode.yml с этими настройками. Сначала попробуйте без него и прокомментируйте этот пост, чтобы сообщить мне. Настройки в IISNode.yml имеют приоритет, если они также установлены в web.config.

debuggingEnabled: значение true здесь имеет значение, но два других значения также важны.

2.Web.Config:параметры, связанные с отладкой в ​​web.config, закомментированы, когда вы впервые открываете web.config шаблона, опять же из соображений безопасности. Раскомментируйте их следующим образом (или, если вы начали работать с обычным Web.config, просто добавьте их):

Я немного изменил комментарии, чтобы они имели больше смысла в этой статье.

Первый тег: iisnode — это место, где начинается волшебство для нашего путешествия Node.js с IIS, естественно, это также первое место, которое требует изменений, когда приложение выполняется с узлом отладки.

Вторым интересным моментом является добавление тега, в который добавляется обработчик NtvsDebugProxy. Он содержит GUID (в вашем случае измените его на указанный выше). Этот GUID будет добавлен после URL-адреса приложения, и при вызове (из отладчика или из браузера) будет выполняться .dll, который мы добавили в папку bin.

Visual Studio имеет инструмент генератора GUID, вы можете использовать его:

Последнее изменение, внесенное в группу тегов system.webServer, — это фактическое правило URL-Rewrite, которое позволяет IIS возвращать ответ при входящем запросе к URL-адресу с указанным выше GUID.

В нижней части группы тегов system.web требуется одно небольшое изменение. customErrors mode="Off", как следует из названия, позволит вам увидеть настоящие ошибки, а не упрощенные для посетителей. Поскольку мы занимаемся отладкой, нам нужно посмотреть, что происходит.

3. Я предполагаю, что вы уже добавили Microsoft.NodejsTools.WebRole.dll в папку /bin, поэтому следующим шагом будет перезапуск нашего приложения Node.js в IIS, чтобы изменения вступили в силу. Вы можете остановить сервер (в диспетчере IIS), запустить его снова, а затем отправить запрос на свой URL-адрес (в браузере), чтобы первый запрос запустил наше приложение. Это убьет предыдущий процесс Node.js и запустит новый в режиме отладки. Вы можете открыть Диспетчер задач на своем сервере, открыть вкладку «Подробности», и должен быть один или несколько процессов node.exe, один из которых указывает, что физическая папка вашего приложения должна начинаться (столбец командной строки) с node.exe — отладка «C:\Program…

Теперь мы можем проверить, правильно ли установлены настройки и загружается ли файл .dll, просто введя URL-адрес нашего сервера и добавив в конце путь с этим GUID, добавленным в web.config в адресной строке вашего браузера, и нажмите Enter. Например:

http://mymadeuptesturl.com/ntvs-debug-proxy/b855eacd-ddf4-4ffc-bee5-9a71981a395f

Вы должны увидеть такую ​​страницу в своем браузере:

Это означает, что .dll, который мы скопировали в папку bin, работает. Как вы видите, выделенный жирным шрифтом внизу этой страницы, есть URL-адрес, похожий на тот, который мы только что ввели в адресную строку браузера, но он начинается с wss://. Это Адрес WebSocket для подключения Visual Studio к сеансу удаленной отладки.

4. Пришло время подключить нашу Visual Studio к серверу. Перейдите в «Отладка» ⇒ «Присоединить к процессу», как показано на скриншоте:

В его окне выберите Удаленная отладка Node.Js из раскрывающегося списка Транспорт и вставьте этот URL, начинающийся с wss, в Квалификатор и нажмите «Найти».

Открывается окно Найти, кнопка Удаленные подключения имеет странное поведение:

Даже если ваша установка готова к подключению через WebSocket, она показывает Найдено 0 подключений. Это неправильно, просто закройте это окно и вернитесь в окно «Присоединить процесс», где вы должны увидеть, что ваш URL-адрес wss добавлен в список Доступные процессы ниже. Если вы по-прежнему не видите его, установите или снимите флажок Показать процессы всех пользователей внизу, чтобы обновить этот список.

Когда вы нажимаете кнопку «Присоединить», это занимает несколько секунд в зависимости от вашего подключения, после чего вы должны подключиться к своему серверу из отладчика Visual Studio. Отправка запроса в ваше веб-приложение приведет к его приостановке в назначенной точке останова, и вы сможете воспользоваться отладчиком Visual Studio, как вы привыкли.

Не забудьте вернуться к разделам web.config, связанным с отладкой, когда закончите, остановите IIS и перезапустите. Вам не нужно удалять Microsoft.NodejsTools.WebRole.dll из папки bin, так как, когда web.config возвращается обратно, эта dll будет бесполезна, пока не будет установлен другой сеанс отладки.

Одна из основных причин, по которой мне больше нравится отладка Node-Inspector, заключается в отсутствии необходимости останавливать/перезапускать сервер. Он создает еще один процесс для целей отладки.

Я потратил довольно много времени на настройку Node.js в IIS, поэтому надеюсь, что вам не придется это делать после прочтения этих сообщений в блоге.