Сообщений 2    Оценка 241        Оценить  
Система Orphus

Удаленная отладка в Visual Studio.NET 2003

Автор: Виктор Юров
НПФ "Энергосоюз"

Источник: RSDN Magazine #4-2004
Опубликовано: 05.03.2005
Исправлено: 13.03.2005
Версия текста: 1.0
Введение
Доступные средства удаленной отладки
Отладка через Remote Debug Monitor
Отладка через DCOM и Machine Debug Manager
Полигон для испытаний
Настройка системы безопасности
Отладка неуправляемого C/C++ кода
Отладка GUI-приложений
Отладка Web-приложения ASP.NET
Отладка T-SQL

Исходный код к статье

Введение

В данной статье рассматриваются дополнительные возможности среды VS.NET 2003, позволяющие выполнять удаленную отладку неуправляемого и управляемого кода, а также T-SQL-запросов. Для рядовых разработок зачастую достаточно возможностей локальной отладки, предоставляемых VS. Но большинство современных программных систем имеют сложную многоуровневую архитектуру, часть компонентов которой вообще не может работать на машине разработчика, так как требует установки внушительного списка программ или подключения специального оборудования. Многие разработчики сталкиваются с массой неудобств при тестировании своего кода на разных операционных системах. Современный рынок требует от программных продуктов поддержки как можно большего числа ОС, а выпуск работоспособного и качественного ПО без тщательного тестирования на всех поддерживаемых ОС невозможен. Существенно упростить жизнь разработчика при поиске и исправлении ошибок может удаленная отладка. Предположим, мы разрабатываем обычное Windows- или Web-приложение, которое должно работать на ОС Windows 98/Me/NT/2000/XP. Например, под Windows Me наш код ну никак не хочет работать. Мы можем приблизительно определить место, где возникает ошибка, и даже набор условий, при которых она возникает, но этой информации во многих случаях недостаточно. К счастью, существуют программы, позволяющие создавать виртуальные машины.

ПРИМЕЧАНИЕ

В настоящее время существует ряд программных продуктов, позволяющих создавать виртуальные машины, устанавливать на них операционные системы, запускать программы и т.д. Наиболее известными из них являются VM Ware Workstation и Virtual PC. Производительность виртуальных машин значительно ниже производительности компьютера, на котором они работают. Для тестирования своих разработок я создал виртуальные машины Windows NT/2000/98 и перед выпуском очередной версии продукта выполняю полный цикл тестов на каждой из них.

Для отладки кода на виртуальную машину можно установить Microsoft Visual Studio .NET 2003 и попробовать произвести отладку локально, но, граждане, поберегите свои нервы. :) VS .NET 2003 будет ставиться дня два. Вдобавок, она может капризничать и не хотеть устанавливаться. Наиболее подходящий выход – использование удаленной отладки. Что ж, как говориться, lets go.

Доступные средства удаленной отладки

В предыдущей версии, MS Visual Studio 6.0, удаленная отладка C/C++-проектов была доступна через Remote Debug Monitor, а сценарии ASP можно было отлаживать в Visual InterDev через Machine Debug Manager. Как известно, в те далекие времена .NET еще только зарождалась, и про управляемый код только ходили слухи. Появление .NET не привело к каким-то изменениям в инфраструктуре отладки MS Visual Studio. В VS .NET 2003 по-прежнему используются следующие способы удаленной отладки:

При удаленной отладке запуск отладчика может осуществляться двумя способами. Первый способ – это настроить свойства проекта. Тогда отладчик VS по команде Start Debug будет автоматически запускать процесс на удаленной машине. В этом случае работу процесса можно целиком отследить с момента создания до момента завершения. Второй способ – это подключиться к уже запущенному процессу, поставить Breakpoint и отладить нужные участки кода. Для присоединения отладчика VS к процессу предназначена команда Debug->Processes (рисунок 1). В поле Transport можно выбрать способ взаимодействия с удаленной машиной: TCP/IP, Pipe или Default. Под Default здесь подразумевается DCOM-соединение. Для использования TCP/IP и Pipe необходимо запустить msvcmon на выбранном компьютере. В поле Name задается имя или IP-адрес компьютера. По команде Attach происходит запуск отладчика и подключение к выбранному процессу. При этом заданные свойства удаленной отладки активного проекта игнорируются.


Рисунок 1. Диалог Debug-Processes.

В VS .NET 2003 также значительно увеличились возможности отладки T-SQL. Теперь можно открыть окно Server Explorer, открыть соединение, выбрать БД, хранимую процедуру и запустить ее на выполнение, предварительно задав входные параметры. Выполнять отладку T-SQL можно как на локальном, так и на удаленном компьютере. В случае удаленной отладки взаимодействие осуществляется через тот же Machine Debug Manager через DCOM. В VS .NET 2003 можно выполнять отладку управляемого кода и T-SQL в одной отладочной сессии. При этом среда VS позволяет устанавливать точки останова внутри хранимых процедур и функций. Для отладки T-SQL на удаленный компьютер необходимо установить пакет SQL Debugging Components. Этот пакет входит в Remote Components Setup и в Full Debugging Setup. Пример отладки T-SQL будет рассмотрен далее в этой статье.

Отладка через Remote Debug Monitor

Для отладки через Remote Debug Monitor необходимо установить и вручную запустить на удаленной машине отладочный монитор (Remote Debug Monitor). Remote Debug Monitor – это небольшое консольное приложение msvcmon, которое взаимодействует с отладчиком VS по TCP/IP или каналы (Pipes). Установка отладочного монитора выполняется при установке Remote Components или Full Remote Debugging. Программа установки копирует его в подкаталог <VS.NET 2003>\Common7\Packages\Debugger.

Можно установить Remote Debug Monitor вручную. Для этого необходимо на удаленную машину скопировать следующие файлы:

Можно также запустить msvcmon из доступного по сети каталога:

По умолчанию msvcmon использует каналы. Параметры сессии msvcmon задаются из командной строки. В таблице 1 приведены основные ключи msvcmon.

КлючНазначениеПримечание
-tcpipИспользовать протокол TCP/IP.
-registerРегистрация отладочного монитора. Отладочный монитор будет автоматически запускаться при запуске отладчика VS.
-anyuserПозволяет выполнять отладку всем пользователям.Только для TCP/IP
-u domain/usernameУчетная запись, которой разрешено подключение.Только для TCP/IP
-maxsessionsЗадает максимальное число одновременных соединений с монитором.Только для TCP/IP
-timeout nn – задает таймаут для соединений.Только для TCP/IP
Таблица 1. Основные ключи Remote Debug Monitor.

Отладка через DCOM и Machine Debug Manager

Machine Debug Manager (MDM) – это утилита удаленной отладки, использующая DCOM. MDM работает как служба и может быть установлена на удаленный компьютер следующими способами:

Последние два варианта позволяют выполнять только отладку неуправляемого C/C++ кода. Для отладки управляемого кода и всевозможных скриптов (VBScript, JScript, T-SQL) необходимо либо целиком установить VS .NET 2003 (только зачем тогда вообще удаленная отладка?), либо установить Full Remote Debugging, что мы и сделаем далее.

При отладке неуправляемого кода Machine Debug Manager автоматически запускает Remote Debug Monitor.

Полигон для испытаний

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

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

На виртуальной машине я установил только Full Remote Debugging и IIS для возможности отладки ASP.NET Web Application и ASP.NET Web Service. Для тестовых проектов я создал каталог C:\RDebug, в котором будут размещаться исполняемые файлы.

Для установки Full Remote Debugging необходимо запустить программу установки VS.NET 2003 следующим образом:

ПРИМЕЧАНИЕ

msiexec /qb+ /i n:\<Visual Studio .NET CD1>\vs_setup.msi NOVSUI=1 TRANSFORMS="n:\<Visual Studio .NET CD1>\Setup\Rmt9x.mst" SERVER_SETUP=1 ADDLOCAL=Full_Remote_Debugging

Настройка системы безопасности

Инфраструктура удаленной отладки накладывает несколько существенных ограничений по безопасности:

  1. Пользователь, выполняющий отладку, не может запустить или присоединиться к процессу, который был запущен под другой сессией Terminal Server.
  2. Если пользователь, выполняющий отладку, не является администратором, он не может присоединиться к процессу, который был запущен под системной или иной учетной записью.
  3. Пользователь, выполняющий отладку, не может запускать процессы на удаленной машине до тех пор, пока он не выполнил вход локально или через Terminal Server.
  4. Пользователь, выполняющий отладку, не может запускать процессы на удаленной машине под чужим именем.
  5. Пользователь вообще не может осуществлять отладку, если он не является администратором и не входит в группу Debugger Users.
  6. Члены группы Debugger Users могут отлаживать только процессы, запущенные под принадлежащими им учетными записями.
  7. Для отладки T-SQL необходимо иметь права на запуск процедуры sp_sdidebug.

Ограничения 1, 2 и 3 могут быть сняты с помощью установки ключа (тип DWORD)

[HKLM\Software\Microsoft\Machine Debug Manager\AllowLaunchAsOtherUser]

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

Доступ к Machine Debug Manager настраивается средствами DCOM. По умолчанию в ОС Windows 2000/XP Pro, Windows 2003 Server доступ разрешен группам Administrators (Администраторы в русской версии) и Debugger Users. В ОС Windows 98/95/Me по умолчанию доступ запрещен.

Если зайти на локальную и удаленную машины под разными учетными записями, то из VS нельзя будет осуществить запуск процесса. При попытке это сделать будет выдана ошибка (рисунок 2). Это происходит в связи с ограничением 4. Произвести отладку в этом случае можно только путем ручного запуска и последующим присоединением к процессу. При использовании одной и той же учетной записи можно запускать процессы для отладки на удаленной машине прямо из VS.


Рисунок 2. Ошибка при запуске отладчика, когда на удаленной машине выполнен вход под другой учетной записью.

Отладка неуправляемого C/C++ кода

Начнем поиски правды с отладки простого консольного приложения. Создадим новый Solution RDebug, а в нем новый проект RNative на основе шаблона Visual C++->Win32 Console Application. Ниже приведен листинг файла RNative.cpp.

#include "stdafx.h"
#include <conio.h>
#include <windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
  // получаем имя компьютера
  TCHAR szCompName[MAX_COMPUTERNAME_LENGTH + 1];
  DWORD dwSize = MAX_COMPUTERNAME_LENGTH + 1;
  BOOL bSuccess = GetComputerName(szCompName, &dwSize);
  if (!bSuccess)
  {
    printf("Error getting computer name: %d", GetLastError());
    return -1;
  }
  // формируем сообщение
  TCHAR szMessage[256];
  sprintf(szMessage, "Hello from %s !", szCompName);
  // выводим сообщение
  OutputDebugString(szMessage);
  printf(szMessage);
  getch();

  return 0;
}

Для проверки запустим программу на локальной машине. Убедимся, что появляются сообщения в окне Output и на консоли. Теперь перейдем к настройке проекта для отладки на удаленной машине. Настройки удаленной отладки задаются на закладке Debugging в Project Properties (рисунок 3).


Рисунок 3. Вкладка Debugging.

В группе Remote Settings задаются параметры Connection, Remote Machine и Remote Command. В поле Connection - тип соединения: “Remote via DCOM”, “Remote via Pipe” или “Remote via TCP/IP”. В данном случае будет использоваться “Remote via Pipe”. В поле Remote Machine нужно задать имя компьютера, на котором будет производиться отладка. Имя моей виртуальной машины – w2k. В поле Remote Command необходимо ввести путь и имя исполняемого файла на удаленной машине, который будет запускаться при запуске отладчика VS. Путь к файлу RNative.exe на машине w2k – C:\RDebug\RNative\RNative.exe. Для того чтобы исполняемый файл по команде Build помещался в каталог C:\RDebug\RNative\, необходимо параметру Output File на закладке Linker->General присвоить значение \\w2k\RDebug\RNative\RNative.exe. Также необходимо, чтобы файл pdb находился в этом же каталоге, поэтому параметру Linker->Debugging необходимо присвоить значение \\w2k\RDebug\RNative\RNative.pdb.

Проект готов. Приступаем к запуску. На удаленной машине нужно войти в систему под той же учетной записью, что и на локальной, и запустить отладочный монитор msvcmon. Теперь нужно произвести сборку проекта, после чего запустить отладчик. В отладочном окне и на консоли появится сообщение “Hello from W2K!”.


Рисунок 4. Удаленная отладка Win32 Console Application.

При отладке через Pipe Remote Debug Monitor предоставляет возможность задавать разрешения на отладку либо всем пользователям, либо определенному пользователю (см. ключи –u и –anyuser).

Отладка GUI-приложений

Создадим новый Solution RDebug, а в нем новый проект RWinApp из шаблона Visual C#->Windows Application. Затем добавим компонент Perfomance Counter и настроим его на счетчик объема доступной памяти.


Рисунок 5. Проект Windows Application.

Добавим обработчик нажатия кнопки “Debug me”:

    private void button1_Click(object sender, System.EventArgs e)
    {
      float val = pcMemory.NextValue();
      string text = string.Format("Aviable memory: {0} Mb", val);
      Console.WriteLine(text);
      MessageBox.Show(text);
      System.Diagnostics.Trace.WriteLine(text);
      System.Diagnostics.Trace.Assert(false);
    }  

Итак, приложение готово. Теперь необходимо подготовить его к удаленной отладке. Для этого нужно открыть Project Properties и выбрать ветку Debugging (рисунок 6).


Рисунок 6. Вкладка Debugging проекта RWinApp.

Для удаленной отладки нужно параметр Enable Remote Debugging установить в True, а параметру Remote Debug Machine присвоить имя удаленной машины. Также необходимо изменить параметры запуска приложения: параметру Debug Mode присвоить значение Program, а параметру Start Application – полный путь к исполняемому файлу на удаленной машине. На машине w2k полный путь к программе RWinApp - C:\RDebug\RWinApp\RWinApp.exe. Для того чтобы после каждой сборки не копировать файлы RWinApp.exe и RWinApp.pdb, можно изменить параметр Output Path в ветке Build. На машине w2k я открыл доступ к каталогу RDebug, а параметру Output Path присвоил значение \\w2k\RDebug\RWinApp\. Проект Windows Application на VB .NET настраивается аналогично.

Проект готов к удаленной отладке. Можно запустить программу. Console.WriteLine при этом ничего не пишет (рисунке 7), System.Diagnostics.Trace.WriteLine выдал текст в окно Output, а System.Diagnostics.Trace.Assert дал о себе знать везде.


Рисунок 7. Удаленная отладка GUI-приложения.

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

Теперь попробуем отладить Web-приложение на удаленной машине. Здесь все гораздо легче. При запуске Web-приложения отладчик выполняет auto-attach, поэтому входить на локальную и удаленную машины под одной учетной записью вовсе не обязательно. Однако пользователь, выполняющий отладку, должен быть администратором на удаленной машине. Как дать возможность удаленной отладки ASP.NET-приложений пользователям из Debugger Users, описано в статье “ASP Remote Debugging Setup” в MSDN.

Приступим к созданию простого Web-приложения. Добавим в Solution новый проект из шаблона Visual C#->ASP.NET Web Application. В поле Location укажем http://w2k/RWebApp.


Рисунок 8. Проект Web-приложения для удаленной отладки

Добавим к форме любимую кнопку “Debug me” и в обработчике нажатия напишем:

private void Button1_Click(object sender, System.EventArgs e)
{      
  string text = string.Format("Hello from {0}", Server.MachineName);  
  System.Diagnostics.Trace.WriteLine(text);
  System.Diagnostics.Trace.Assert(false);
}

В случае ASP.NET-приложений задание каких-то свойств проекта для выполнения удаленной отладки не требуется. Запускаем приложение. При нажатии на кнопку в окне Output появится сообщение “Hello from W2K!” и информация о месте возникновения Assert.


Рисунок 9. Удаленная отладка Web-приложения ASP.NET.

Отладка T-SQL

Как уже было сказано выше, VS .NET 2003 позволяет выполнять одновременно отладку T-SQL и кода приложения в одной отладочной сессии. Приложение, вызывающее хранимые процедуры или функции, может работать локально или удаленно, при этом местонахождение SQL-сервера не играет особой роли. Для отладки T-SQL на сервере необходима установка пакета SQL Debugging Components. Отладчик T-SQL имеет следующие ограничения:

Взаимодействие сервера и клиента при отладке осуществляется через DCOM. В связи с этим задание прав на отладку может осуществляться средствами DCOM и SQL Server. Отладка T-SQL производится с помощью расширенной хранимой процедуры sp_sdidebug. Соответственно, пользователь, выполняющий отладку, должен иметь право запуска этой процедуры. Если отладка T-SQL осуществляется удаленно, то необходимо, чтобы служба MSSQLSERVER работала не под учетной записью LocalSystem. Если при работе отладчика на сервере возникают какие-то ошибки, они фиксируются в журнале приложений.

Перейдем к рассмотрению типовых задач отладки T-SQL. Для начала рассмотрим самую простую задачу – отладку хранимых процедур из VS. Для этого нужно открыть Server Explorer и добавить новое соединение в Data Connections, затем выбрать Step Into Stored Procedure. Я в качестве примера выбрал процедуру SalesByCategory из БД Northwind. Перед запуском отладчик запрашивает необходимые параметры. Для процедуры SalesByCategory я ввел @CategoryName=’Confections’, @OrdYear= <DEFAULT>. После запуска происходит остановка на первой же инструкции (рисунок 10).


Рисунок 10. Отладка хранимой процедуры.

Если нужно отладить T-SQL, вызываемый из программы, можно поставить в нем точку останова. Для иллюстрации этого откроем проект RWebApp, в нем форму WebForm1.aspx. Перетащим на нее хранимую процедуру SalesByCategory. В результате на форме появятся объекты sqlConnection1 и sqlCommand1. После этого можно в обработчик Page_Load добавить следующий код:

private void Page_Load(object sender, System.EventArgs e)
{
  // Put user code to initialize the page here
  sqlConnection1.Open();
}

Теперь добавим на форму еще одну кнопку “Debug SQL” и в обработчике ее нажатия напишем:

private void Button2_Click(object sender, System.EventArgs e)
{
  try
  {
    sqlCommand1.Parameters["@CategoryName"].Value = "Confections";
    int retCode = sqlCommand1.ExecuteNonQuery();
  }
  catch (System.Data.SqlClient.SqlException ex)
  {
    System.Diagnostics.Trace.WriteLine(ex.Message);
  }  
}

После этого соберем проект, поставим точку останова в процедуре SalesByCategory и запустим приложение. По нажатию на кнопку “Debug SQL” происходит остановка на этой точке останова.


Эта статья опубликована в журнале RSDN Magazine #4-2004. Информацию о журнале можно найти здесь
    Сообщений 2    Оценка 241        Оценить