Проблемы с отладкой командлета PowerShell

Я использую Visual Studio 2010 для 64-разрядной версии Windows 7. У меня возникла проблема с отладкой специального командлета PowerShell.

Конфигурация

  • Язык: С#, предназначенный для .NET Framework 3.5 SP1.
  • Цель платформы: любой процессор
  • Начало действия: C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe
  • Аргументы командной строки: -noexit -command Add-PSSnapIn MyCustomSnapIn

Проблема 1: Не удалось подключиться, когда я нажимаю F5 (Debug → Start Debugging)

  • PowerShell открывается, а диспетчер задач указывает, что powershell.exe работает как 64-разрядный процесс. В столбце "Имя пути к изображению" показан тот же исполняемый файл, который указан в действии "Пуск".
  • Если я выберу Debug → Перерыв Все в Visual Studio, я получаю сообщение "Невозможно разорвать выполнение. Этот процесс в настоящее время не выполняет тип кода, который вы выбрали для отладки".

Проблема 2: Неожиданно запускается как 32-разрядный процесс, когда я нажимаю Ctrl + F5 (Debug → Start Without Debugging)

  • Откроется PowerShell. Диспетчер задач указывает, что powershell.exe работает как 32-битный процесс - на этот раз имя пути изображения отображает перенаправление SysWOW64.

Досадный способ отладки прямо сейчас: Единственный способ, которым я нашел отладку моего командлета, - нажать F5, затем выбрать Debug → Отсоединить все, затем выбрать Debug → Прикрепить к процессу и снова подключиться Visual Studio.

Ответы

Ответ 1

Проблема 1:

Мне кажется, что ошибка в VS2010 представлена ​​здесь: https://connect.microsoft.com/VisualStudio/feedback/details/539389/debugging-powershell-cmdlet-from-vs-2010-does-not-stop-at-breakpoints?wa=wsignin1.0

Использование VS2008 должно помочь.

Обновление: Я нашел более удобный способ отладки командлетов powershell. В редакторе решений щелкните правой кнопкой мыши по решению node → Добавить → Новый проект → Выберите файл powershell.exe(C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe). Установите новый добавленный проект в качестве запуска проекта (щелкните правой кнопкой мыши и выберите "Установить как проект запуска" ). Затем перейдите к свойствам проекта (щелкните правой кнопкой мыши по проекту node и выберите "Свойства" ) и установите для свойства "Тип отладчика" значение "Управляемый (v2.0, v1.1, v1.0)". Не забудьте зарегистрировать своего провайдера или CmdLet (запустив события пост-сборки, см. http://msdn.microsoft.com/en-us/library/ms714644%28v=vs.85%29.aspx). Теперь программа должна остановиться в точке останова.

Ответ 2

В задаче № 2, поскольку Visual Studio - это 32-разрядный процесс, запущенный на WOW64, путь C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe перенаправляется на C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe. Вот где живет 32-разрядная версия PowerShell.

Ответ 3

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

Я обнаружил, что для PowerShell 2.0 для меня работает следующий сценарий. Я также использую VS2010 SP1 в 64-разрядной версии Windows 7.

С PS 2.0 вам не нужно устанавливать командлеты с помощью installutil. Вместо этого вместо этого вы можете использовать Import-Module (для которого не требуется права администратора). Я не буду вдаваться в подробности о том, как это делается как веб-поиск, и выявит большинство деталей, но, в общем, вам нужно будет создать папку (если она еще не существует):

md (Join-Path (Split-Path $profile) modules)

В папке с модулями создайте другую папку с тем же именем, что и DLL командной строки (минус ".DLL" ). Эта папка будет содержать ваш двоичный файл и файл psd1, который описывает вашу DLL (см. Манифест модуля > ). Для моего удобства я создал эту папку в виде символической ссылки папки в папку bin\debug проектов.

Вам все равно нужно запустить PowerShell (или PowerShell ISE) из Visual Studio, как описано в другом разделе "Начало действия" на вкладке "Отладка" свойств проекта.

Установите точки останова и идите. После запуска PowerShell введите:

Import-Module <ModuleName>

Затем запустите ваш командлет.

Пример

C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.dll 
C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.pdb
C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.psd1
C:\Users\<me>\Documents\WindowsPowerShell\modules\MyCmdlet\MyCmdlet.Types.ps1xml (etc.)

В типе PowerShell (также может быть помещен в ваш профиль):

Import-Module MyCmdlet

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

Ответ 4

Проблема 1: powershell.exe на самом деле не управляемый исполняемый файл. В нем размещается сама среда CLR, поэтому вам необходимо включить встроенную отладку кода вместе с управляемым для этого.

Что касается проблемы 2, я не уверен в этом. Очевидно, что сам VS является 32-битным процессом, поэтому, возможно, он вмешивается здесь.

Ответ 5

Мне удалось решить проблему №2, создав папку C:\dev\PowerShell\x64 и скопировав все из C:\Windows\System32\WindowsPowerShell\v1.0 в нее. Я создал аналогичную папку C:\dev\PowerShell\x86. Предполагаемая версия PowerShell всегда запускается, когда я укажу эти пути, поэтому самый короткий способ начать отладку - это "Начать без отладки", а затем "Присоединить к процессу".

Ответ 6

Вы не упомянули, как вы устанавливаете плагин перед вызовом Add-PSSnapin, чтобы сделать его пригодным для использования в сеансе отладки.

Убедитесь, что вы устанавливаете плагин с помощью C:\Windows\Microsoft.NET\Framework64\v2.0.50727\InstallUtil.exe, а не тот, который находится в... \Framework... - это заставило меня за пару дней.

Ответ 7

У меня была эта проблема с VS2010, но она ушла после установки SP1.