Проблемы при отладке командлета PowerShell - PullRequest
11 голосов
/ 25 июля 2010

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

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

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

Проблема 1: Не удается подключиться при нажатии клавиши F5 (Отладка → Начать отладку)

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

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

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

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

Ответы [ 7 ]

6 голосов
/ 27 июля 2010

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

2 голосов
/ 28 августа 2011

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

Я обнаружил, что следующий сценарий работает для меня с 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

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

2 голосов
/ 26 июля 2010

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

1 голос
/ 26 июля 2010

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

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

0 голосов
/ 21 октября 2011

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

0 голосов
/ 20 августа 2010

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

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

0 голосов
/ 26 июля 2010

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

...